Проект рекомендации RFC. Предполагаемый статус: информационный Срок действия истекает: 11 июня 2009 г. Г. Чудов, ред. С. Леонтьев, ред. Компания «КРИПТО-ПРО» 8 декабря 2008 г. ГОСТ 28147-89 Набор алгоритмов шифрования для протокола безопасности транспортного уровня (TLS) draft-chudov-cryptopro-cptls-04 Статус этого документа Этот проект рекомендации RFC представляется в Группу инженерной поддержки Интернета (IETF) в полном соответствии с положениями стандартов BCP 78 и BCP 79. Проекты рекомендаций RFC являются рабочими документами Группы инженерной поддержки Интернета(IETF), ее областей применения и ее рабочих групп. Обратите внимание, что другие группы также могут распространять рабочие документы в виде проектов рекомендаций RFC. Проекты рекомендаций RFC являются проектными документами, действительными в течение не более шести месяцев, которые в любое время могут быть обновлены, заменены или перекрыты другими документами. Проекты рекомендаций RFC нецелесообразно использовать в качестве справочного материала или ссылаться на них иначе, чем как на «незавершенный проект». Список текущих проектов рекомендаций RFC можно получить по адресу http://www.ietf.org/ietf/1id-abstracts.txt. Список альтернативных каталогов проектов рекомендаций RFC можно получить по адресу http://www.ietf.org/shadow.html. Срок действия этого проекта рекомендации RFC истекает 11 июня 2009 г. Уведомление об авторских правах © Доверенные лица IETF и лица, определенные как авторы документа, 2008. Все права защищены. Этот документ является объектом прав, лицензий и ограничений, описанных в BCP 78 и правовых положениях IETF, относящимся к документам IETF (http://trustee.ietf.org/license-info), действующим на момент опубликования данного документа. Мы настоятельно рекомендуем внимательно ознакомиться с вышеуказанными документами, поскольку в них описываются ваши права и накладываемые ограничения в отношении настоящего документа. Аннотация Настоящий документ предназначен для регистрации новых наборов алгоритмов шифрования протокола безопасности транспортного уровня (Transport Layer Security, TLS) в соответствии с процедурой, Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 1] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. указанной в стандартах протокола TLS. Эти наборы алгоритмов шифрования основаны на российских государственных криптографических стандартах – открытые ключи в соответствии со стандартами ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001, алгоритм шифрования ГОСТ 28147-89 и алгоритм хеширования ГОСТ Р 34.11-94. Оглавление 1. Введение . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Определения наборов алгоритмов шифрования . . . . . . . .3 2.1. Обмен ключами . . . . . . . . . . . . . . . . . . . . .3 2.2. Псевдослучайная функция, подпись и хеширование . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Алгоритм шифрования и MAC . . . . . . . . . . . . . . .4 3. Структуры данных и вычисления . . . . . . . . . . . . . .5 3.1. Алгоритмы . . . . . . . . . . . . . . . . . . . . . . .5 3.2. Вычисление ключей . . . . . . . . . . . . . . . . . . .5 3.3. Сертификат сервера . . . . . . . . . . . . . . . . . . 5 3.4. Обмен серверными ключами . . . . . . . . . . . . . . . 5 3.5. Запрос на получение сертификата . . . . . . . . . . . .6 3.6. Сообщение об обмене ключа клиента . . . . . . . . . . .6 3.7. Проверка сертификата . . . . . . . . . . . . . . . . . 8 3.8. Завершение . . . . . . . . . . . . . . . . . . . . . . 9 4. Совместимость . . . . . . . . . . . . . . . . . . . . . .9 5. Вопросы безопасности . . . . . . . . . . . . . . . . . . 9 6. Согласование с IANA . . . . . . . . . . . . . . . . . . .9 7. Ссылки . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Ссылки на нормативные документы . . . . . . . . . . . .10 7.2. Информационные ссылки . . . . . . . . . . . . . . . . .12 Приложение A. Модули ASN.1 . . . . . . . . . . . . . . . . .12 A.1 ГОСТ КриптоПро-TLS . . . . . . . . . . . . . . . . . . .12 Приложение Б. Благодарности . . . . . . . . . . . . . . . . 14 Адреса авторов . . . . . . . . . . . . . . . . . . . . . . .15 Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 2] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. 1. Введение В этом документе представлены новые дополнительные наборы алгоритмов шифрования к протоколу безопасности транспортного уровня (Transport Layer Security, TLS) для поддержки хеширования ГОСТ Р 34.11-94, шифрования ГОСТ 28147-89 и алгоритмов обмена ключами ГОСТ Р ВКО 34.10-94/2001. Определенные тут наборы алгоритмов шифрования были предложены компанией «КРИПТО-ПРО» для участников Соглашения о совместимости криптографических средств российских разработчиков. Алгоритмы ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001, ГОСТ 28147-89 и ГОСТ Р 34.11-94 разработаны Российским федеральным агентством правительственной связи и информации (ФАПСИ) и Всероссийским научно-исследовательским институтом стандартизации. Они описаны в [GOSTR341094], [GOSTR341001], [GOSTR341194] и [GOST28147] ([GOST3431095], [GOST3431004], [GOST3431195]). Алгоритмы ВКО ГОСТ Р 34.10-94/2001 и PRF_GOSTR3411 описаны в [CPALGS]. В этом документе определяются две конфигурации: анонимный клиент – аутентифицированный сервер (сертификат предоставляет только сервер); аутентифицированный клиент - аутентифицированный сервер (клиент и сервер обмениваются сертификатами). Используемый здесь язык представления такой же, как и в [TLS1.2]. Так как эта спецификация расширяет [TLS1.2], эти описания должны быть объединены с теми, которые находятся в спецификации протокола TLS, и всеми другими, которые расширяют протокол TLS. Это означает, что перечисляемые типы могут не определять все возможные значения и структуры с множеством форматов, выбранных с помощью оператора select(). Они могут не отображать все возможные случаи. Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «НУЖНО», «НЕ НУЖНО», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «НЕОБЯЗАТЕЛЬНО», встречающиеся в данном документе, следует интерпретировать в соответствии с положениями [RFC2119]. 2. Определения наборов алгоритмов шифрования 2.1. Обмен ключами Определенные здесь наборы алгоритмов шифрования используют следующие алгоритмы обмена ключами: Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 3] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. +-------------------------------------+------------------------+ | Набор алгоритмов шифрования | Алгоритм обмена ключами | +-------------------------------------+------------------------+ | TLS_GOSTR341094_WITH_28147_CNT_IMIT | ВКО ГОСТ Р 34.10-94 | | TLS_GOSTR341001_WITH_28147_CNT_IMIT | ВКО ГОСТ Р 34.10-2001 | | TLS_GOSTR341094_WITH_NULL_GOSTR3411 | ВКО ГОСТ Р 34.10-94 | | TLS_GOSTR341001_WITH_NULL_GOSTR3411 | ВКО ГОСТ Р 34.10-2001 | +-------------------------------------+------------------------+ Алгоритмы создания производного ключа, основанные на открытых ключах ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001 (ВКО ГОСТ Р 34.10-94, ВКО ГОСТ Р 34.10-2001), описаны в [CPALGS]. 2.2. Псевдослучайная функция, подпись и хеширование Описанные здесь наборы алгоритмов шифрования используют псевдослучайные функции HMAC и TLS в соответствии с описанием, представленным в разделе 5 [TLS1.2], на основе хеш-функции ГОСТ Р 34.11-94 (HMAC_GOSTR3411 и PRF_GOSTR3411), с набором параметров, определенным в документе id-GostR3411-94-CryptoProParamSet (см. [CPALGS]). Те же псевдослучайные функции ДОЛЖНЫ использоваться для всех соответствующих протоколов, таких как [EAP-TLS]. Подпись ГОСТ Р 34.10-94/2001 используется для сообщения CertificateVerify. Алгоритм хеширования ГОСТ Р 34.11 ([GOSTR341194]) используется для CertificateVerify.signature.gostR3411_hash и Finished.verify_data (см. разделы 7.4.10 и 7.4.11 в [TLS1.2]) 2.3. Алгоритм шифрования и MAC Используются следующие алгоритмы шифрования и MAC-функции (подробнее см. раздел 3.1): +-------------------------------------+-----------+----------------+ | Наборов алгоритмов шифрования | Алгоритм шифрования | MAC | +-------------------------------------+-----------+----------------+ | TLS_GOSTR341094_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 | | TLS_GOSTR341001_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 | | TLS_GOSTR341094_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 | | TLS_GOSTR341001_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 | +-------------------------------------+-----------+----------------+ Для всех четырех наборов алгоритмов шифрования практическое применение МАС немного отличается от описания, указанного в разделе 6.2.3.1 [TLS1.2] для стандартных потоковых алгоритмов шифрования, где MAC рассчитывается исходя из следующих данных: Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 4] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. MACed_data[seq_num] = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment; Определенные в этом документе наборы алгоритмов шифрования используют одинаковые входные данные для первой записи, но для каждой последующей записи входные данные от всех предыдущих записей объединяются: MACed_data[0] + ... + MACed_data[n] 3. Структуры данных и вычисления 3.1. Алгоритмы ГОСТ 28147-89 [GOST28147] использует 256-битовый размер ключа и 8-байтовый вектор инициализации (IV). Определенные здесь наборы алгоритмов шифрования используют ГОСТ 28147-89 в качестве потокового алгоритма шифрования в режиме счетчика с параметром S-box из id-Gost28147-89-CryptoPro-A-ParamSet (см. [CPALGS]) и алгоритм криптографического преобразования ключа КриптоПро. IMIT_GOST28147 является ГОСТом 28147-89 [GOST28147] в режиме IMITOVSTAVKA (4 байта) 3.2. Вычисление ключей Вычисление ключей производится в соответствии с разделом 6.3 [TLS1.2] с использованием PRF_GOSTR3411. Используются следующие параметры: SecurityParameters.enc_key_length = 32 SecurityParameters.mac_key_length = 32 SecurityParameters.fixed_iv_length = 8 Длина необходимого ключевого материала составляет 144 байта. 3.3. Сертификат сервера Для данных наборов алгоритмов шифрования требуется такое сообщение, и оно ДОЛЖНО содержать сертификат с алгоритмом открытого ключа, соответствующим ServerHello.cipher_suite. 3.4. Обмен серверными ключами В этих наборах алгоритмов шифрования данное сообщение использоваться НЕ ДОЛЖНО, так как все необходимые параметры присутствуют в сертификате сервера (см. [CPPK]). Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 5] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. 3.5. Запрос на получение сертификата Это сообщение используется в соответствии с описанием, представленным в разделе 7.4.4 [TLS1.2], а также в расширенном виде: enum { gostr341094(21), gostr34102001(22),(255) } ClientCertificateType; Типы сертификатов gostr341094 и gostr34102001 указывают на то, что сервер принимает сертификаты открытых ключей ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001. enum{ gostr3411(XX) } HashAlgorithm; enum{ gostr341094(XX), gostr34102001(XX) } SignatureAlgorithm; Тип хеширования gostr3411 означает, что сервер принимает функцию хеширования ГОСТ Р 34.11-94. В том случае, когда выбран один из описанных в данном документе наборов алгоритмов шифрования, РЕКОМЕНДУЕТСЯ заполнять CertificateRequest.certificate_hash только значением gostr3411. Серверу СЛЕДУЕТ заполнить поле supported_signature_algorithm парами SignatureAndHashAlgorithm, где HashAlgorithm равно gostr3411, а SignatureAlgorithm совпадает с соответствующим ClientCertificateType. 3.6. Сообщение об обмене ключа клиента Это сообщение используется в соответствии с описанием, представленным в разделе 7.4.7 [TLS1.2]. Оно необходимо для данных наборов и содержит DER-кодированную структуру TLSGostKeyTransportBlob [X.660]. enum { vko_gost } KeyExchangeAlgorithm; struct { select (KeyExchangeAlgorithm) { case vko_gost: TLSGostKeyTransportBlob; } exchange_keys; } ClientKeyExchange; Синтаксис данных ASN1 для этой структуры: Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 6] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. TLSGostKeyTransportBlob ::= SEQUENCE { keyBlob GostR3410-KeyTransport, proxyKeyBlobs SEQUENCE OF TLSProxyKeyTransportBlob OPTIONAL } TLSProxyKeyTransportBlob ::= SEQUENCE { keyBlob GostR3410-KeyTransport, cert OCTET STRING } GostR3410-KeyTransport определен в [CPCMS]. ДОЛЖЕН присутствовать keyBlob.transportParameters. В том случае, если сервер не запрашивал сертификат клиента или алгоритм и параметры открытого ключа клиента не совпадают с алгоритмом и параметрами открытого ключа получателя, то ДОЛЖЕН присутствовать keyBlob.transportParameters.ephemeralPublicKey, иначе его следует пропустить. proxyKeyBlobs – (не обязательно) содержит обмен ключами для вторичных получателей (например, для межсетевого экрана, который проверяет соединения). cert - содержит сертификат вторичного получателя. Действия клиента Сначала клиент генерирует случайное 32-байтовое значение premaster_secret. Затем shared_ukm вычисляется как первые 8 байт хеш-значения объединенных случайных значений клиента и сервера: shared_ukm = GOSTR3411(client_random|server_random)[0..7] Затем клиент выбирает ключ отправителя. Если keyBlob.transportParameters.ephemeralPublicKey присутствует, то в качестве ключа отправителя ДОЛЖЕН быть использован соответствующий секретный ключ. Если он отсутствует, ДОЛЖЕН использоваться секретный ключ, соответствующий сертификату клиента. Для создания ключа шифрования ключей (key-encrypting key, KEK) применяется алгоритм ВКО ГОСТ Р 34.10-94 или ВКО ГОСТ Р 34.10-2001 (описанные в [CPALGS]). При этом используются ключ отправителя и открытый ключ получателя. ВКО ГОСТ Р 34.10-2001 используется вместе с shared_ukm в качестве материала ключа пользователя (UKM). Затем применяется алгоритм КриптоПро для шифрования premaster_secret CEK_ENC и генерации CEK_ENC и CEK_MAC. В этом случае shared_ukm также используется в качестве материала ключа пользователя. keyBlob.transportParameters.encryptionParamSet используется для всех операций шифрования. Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 7] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. Полученный зашифрованный ключ (CEK_ENC) помещается в поле keyBlob.sessionEncryptedKey.encryptedKey, его mac (CEK_MAC) помещается в поле keyBlob.sessionEncryptedKey.macKey, а shared_ukm (UKM) - в поле keyBlob.transportParameters.ukm. Действия сервера: Сервер ДОЛЖЕН проверить, что keyBlob.transportParameters.ukm равен GOSTR3411 (client_random|server_random)[0..7] до начала расшифровки premaster_secret. Сервер применяет ВКО ГОСТ Р 34.10-94 или ВКО ГОСТ Р 34.10-2001 (в зависимости от типа открытого ключа клиента) и аналогичным образом алгоритм расшифровки ключа КриптоПро для расшифровки premaster_secret. После расшифровки premaster_secret сервер ДОЛЖЕН проверить keyBlob.sessionEncryptedKey.macKey. 3.7. Проверка сертификата Это сообщение используется в соответствии с положениями раздела 7.4.8 [TLS1.2]. Если клиент послал и сертификат клиента, и эфемерный открытый ключ, он ДОЛЖЕН послать сообщение о проверке сертификата в качестве доказательства владения закрытым ключом для предоставленного сертификата. Структуры TLS расширены следующим образом: enum { gostr341094, gostr34102001 } SignatureAlgorithm; select (SignatureAlgorithm) { case gostr341094: digitally-signed struct { opaque gostr341194_hash[32]; }; case gostr34102001: digitally-signed struct { opaque gostr341194_hash[32]; }; } Signature; CertificateVerify.signature.gostR3411_hash = GOSTR3411(handshake_messages) Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 8] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. 3.8. Завершение Это сообщение используется в соответствии с описанием, приведенным в разделе 7.4.9 из [TLS1.2]. Finished.verify_data = PRF_GOSTR3411(master_secret, finished_label, GOSTR3411(handshake_messages)) [0..11] 4. Совместимость По историческим причинам некоторые приложения используют наборы алгоритмов шифрования, определенные в настоящем документе и в [TLS1.0], частично используя функционал из [TLS1.2], включая вычисление псевдослучайной функции, зависимой от набора алгоритмов шифрования, сообщения о завершении и сообщения о проверке сертификата. 5. Вопросы безопасности РЕКОМЕНДУЕТСЯ проводить проверку программным обеспечением значения подписи, открытые ключи субъекта и параметры алгоритма на предмет их соответствия стандартам [GOSTR341001], [GOSTR341094] до начала их использования. Использовать один и тот же ключ для подписи и для создания производного ключа НЕ РЕКОМЕНДУЕТСЯ. Если данное расширение присутствует в сертификате, и для клиента, и для сервера РЕКОМЕНДУЕТСЯ выполнять проверку срока использования закрытого ключа. Предлагаемые здесь наборы алгоритмов шифрования TLS_GOSTR341094_WITH_28147_CNT_IMIT и TLS_GOSTR341001_WITH_28147_CNT_IMIT были проанализированы специальной лабораторией сертификации «Научно-технического центра «Атлас» в соответствии с уровнями target_of_evaluation (TOE). РЕКОМЕНДУЕТСЯ направить эти наборы алгоритмов шифрования в уполномоченный орган для рассмотрения с учетом утвержденных методов криптографического анализа. 6. Согласование с IANA В этом документе определяются следующие новые наборы алгоритмов шифрования, значения которых используются в нескольких реализациях одних и тех же наборов алгоритмов шифрования протокола TLS 1.0, и которые были описаны в предыдущих проектах. В настоящее время они перечислены в реестре в качестве зарезервированных. Произведен запрос в IANA на обновление реестра набора алгоритмов шифрования протокола TLS, определенного в [RFC5246] такими значениями. Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 9] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. CipherSuite CipherSuite CipherSuite CipherSuite TLS_GOSTR341094_WITH_28147_CNT_IMIT TLS_GOSTR341001_WITH_28147_CNT_IMIT TLS_GOSTR341094_WITH_NULL_GOSTR3411 TLS_GOSTR341001_WITH_NULL_GOSTR3411 = = = = {0x00,0x80} {0x00,0x81} {0x00,0x82} {0x00,0x83} В этом документе определяются следующие новые типы клиентских сертификатов. Их значения, представленные здесь, используются несколькими реализациями одних и тех же наборов алгоритмов шифрования протокола TLS 1.0 и описаны в предыдущих проектах. В настоящее время они перечислены в реестре в качестве зарезервированных. Произведен запрос в IANA на обновление реестра идентификаторов TLS ClientCertificateType, определенного в [RFC5246], такими значениями: enum { gostr341094(21), gostr34102001(22) } ClientCertificateType; В этом документе определяются следующие новые типы алгоритмов подписи, чьи значения следует присвоить из реестра TLS SignatureAlgorithm, определенного в [RFC5246]. enum{ gostr341094(XX), gostr34102001(XX) } SignatureAlgorithm; В этом документе определяются следующие новые типы алгоритма хеширования, чьи значения следует присвоить из реестра TLS HashAlgorithm, определенного в [RFC5246]. enum { gostr3411(XX) } HashAlgorithm; 7. Ссылки 7.1. Ссылки на нормативные документы [CPALGS] В. Попов, И. Курепкин и С. Леонтьев, «Дополнительные алгоритмы шифрования для использования с алгоритмами ГОСТ 28147-89, ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94», RFC 4357, январь 2006 г. [CPCMS] С. Леонтьев и Г. Чудов, «Использование алгоритмов ГОСТ 28147-89, ГОСТ Р 34.11-94, ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001 с синтаксисом криптографических сообщений (CMS)», RFC 4490 , май 2006 г. [CPPK] С. Леонтьев и Д. Шефановский, «Использование ГОСТ Р Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 10] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. 34.10-94, ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94. Инфраструктура открытого ключа Интернет X.509. Профиль сертификата инфраструктуры и списка отзыва сертификатов (CLR)», RFC 4491, май 2006 г. [GOST28147] Государственный комитет СССР по стандартам, «Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования. Государственный стандарт СССР (на русском языке)», ГОСТ 28147-89, 1989. [GOST3431004] Межгосударственный совет по стандартизации, метрологии и сертификации Содружества Независимых Государств (EASC), Минск, «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма (на русском языке)», ГОСТ 34.3102004, 2004. [GOST3431095] Межгосударственный совет по стандартизации, метрологии и сертификации Содружества Независимых Государств (EASC), Минск, «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма (на русском языке)», ГОСТ 34.310-95, 1995. [GOST3431195] Межгосударственный совет по стандартизации, метрологии и сертификации Содружества Независимых Государств (EASC), Минск, «Информационная технология. Криптографическая защита информации. Хеш-функция (на русском языке)», ГОСТ 34.311-95, 1995. [GOSTR341001] Государственный комитет Российской Федерации по стандартизации, «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи. Государственный стандарт Российской Федерации (на русском языке)», ГОСТ Р 34.10-2001, 2001. [GOSTR341094] Государственный комитет Российской Федерации по стандартизации, «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма. Государственный стандарт Российской Федерации (на русском языке)», ГОСТ Р 34.10-94, 1994. Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 11] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. [GOSTR341194] Государственный комитет Российской Федерации по стандартизации, «Информационная технология. Криптографическая защита информации. Хеш-функция. Государственный стандарт Российской Федерации (на русском языке)», ГОСТ Р 34.11-94, 1994. [TLS1.2] Т. Диркс (T. Dierks) и Е. Рескорла (E. Rescorla), «Протокол TLS», draft-ietf-tls-rfc4346-bis-01(незавершенная работа), июнь 2006 г. 7.2. Информационные ссылки [EAP-TLS] Б. Эбоба (Б. Aboba) и Д. Саймон (D. Simon), «Протокол аутентификации PPP EAP TLS», RFC 2716, октябрь 1999 г. [RFC2119] С. Браднер (S. Bradner), «Ключевые слова для использования в рекомендациях RFC для указания уровня требований», стандарт BCP 14, RFC 2119, март 1997 г. [TLS1.0] Т. Диркс (Т. Dierks) и С. Аллен (C. Allen), «Протокол TLS версии 1.0», RFC 2246, январь 1999 г. [X.660] ИСО/МЭК, «Рекомендация МСЭ-Т Х.660 Информационная технология - правила кодирования ASN.1: Спецификация базовых правил кодирования (BER), канонических правил кодирования (CER) и отличительных правил кодирования (DER)», МСЭ-Т X.660, 1997. Приложение A. Модули ASN.1 Указанные здесь дополнительные модули ASN.1 можно найти в [CPALGS] и [CPCMS]. A.1 ГОСТ КриптоПро-TLS ГОСТ КриптоПро-TLS { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) other(1) modules(1) gost-CryptoPro-TLS(16) 1 } DEFINITIONS ::= BEGIN -- Экспорт всех -Типы и значения, определенные в этом модуле, экспортируются для использования в других модулях ASN.1, содержащихся в российских криптографических спецификациях «ГОСТ» и «ГОСТ Р», и для использования другими приложениями для получения доступа к российским службам криптографии. Другие приложения могут использовать их в своих целях, но это не накладывает никаких ограничений на расширения и изменения, необходимые для поддержания или улучшения российских служб криптографии. Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 12] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. IMPORTS Certificate, AlgorithmIdentifier FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} id-CryptoPro-algorithms, gostR3410-EncryptionSyntax FROM Cryptographic-Gost-Useful-Definitions { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) other(1) modules(1) cryptographic-Gost-Useful-Definitions(0) 1 } GostR3410-KeyTransport FROM GostR3410-EncryptionSyntax gostR3410-EncryptionSyntax ; id-PRF-GostR3411-94 OBJECT IDENTIFIER ::= { id-CryptoPro-algorithms prf-gostr3411-94(23) } TLSProxyKeyTransportBlob ::= SEQUENCE { keyBlob GostR3410-KeyTransport, cert OCTET STRING } TLSGostKeyTransportBlob ::= SEQUENCE { keyBlob GostR3410-KeyTransport, proxyKeyBlobs SEQUENCE OF TLSProxyKeyTransportBlob OPTIONAL } TLSGostSrvKeyExchange ::= SEQUENCE OF OCTET STRING (CONSTRAINED BY {Certificate}) TLSGostExtensionHashHMACSelect ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hmacAlgorithm AlgorithmIdentifier, prfAlgorithm AlgorithmIdentifier } TLSGostExtensionHashHMACSelectClient ::= SEQUENCE OF TLSGostExtensionHashHMACSelect TLSGostExtensionHashHMACSelectServer ::= TLSGostExtensionHashHMACSelect END -- Gost-CryptoPro-TLS Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 13] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. Приложение Б. Благодарности Этот документ был создан в соответствии с документом «Соглашение о совместимости российского криптографического программного обеспечения», подписанным ФГУП «НТЦ «Атлас», компаниями «КРИПТО-ПРО», «Фактор-ТС», МОПНИЭИ, ОАО «ИнфоТеКС», СПБ РЦЗИ, «Криптоком», «Р-Альфа». Целью данного соглашения является достижение взаимной совместимости продуктов и решений. Авторы выражают благодарность: - компании Microsoft Corporation Russia за предоставленную информацию о продуктах и решениях компании, а также за техническую консультацию по инфраструктуре открытого ключа (PKI); - компаниям RSA Security Russia и «Демос» за активное сотрудничество и ценное содействие в создании этого документа; - компании НИП «Информзащита» за проверку на совместимость предлагаемых форматов данных при использовании их в продуктах компании; - компании Citrix Inc за помощь в проверке их продуктов на совместимость с ОС Microsoft Windows; - Русу Хаусли (Russ Hously, компания Vigil Security, LLC, [email protected]) и Василию Сахарову (компания «Демос» , [email protected]) за инициативу, проявленную при создании этого документа. Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 14] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. Адреса авторов Александр Афанасьев Фактор-ТС Пресненский вал, 14, офис 711, Москва, 123557, Россия Эл. адрес: [email protected] Николай Никишин ОАО «ИнфоТеКС» Ленинградский проспект, 80-5, а/я 35, Москва, 125315, Россия Эл. адрес: [email protected] Болеслав Изотов ФГУП НТЦ «Атлас» Ул. Образцова, 38, Москва, 127018, Россия Эл. адрес: [email protected] Елена Минаева МОПНИЭИ Второй Троицкий пер., 6А, строение 3 Москва, Россия Эл. адрес: [email protected] Сергей Муругов Р-Альфа Ул. Расплетина, 4/1, Москва, 123060, Россия Эл. адрес: [email protected] Игорь Устинов Криптоком Ленинский проспект, 51, офис 239, Москва, 119991, Россия Эл. адрес: [email protected] Анатолий Эркин СПБ РЦЗИ Ул. Обручева, 1, Санкт-Петербург, 195220, Россия Эл. адрес: [email protected] Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 15] Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS. Декабрь 2008 г. Адреса авторов Григорий С. Чудов (редактор) ООО «КРИПТО-ПРО» Сущевский вал, 16/5 Москва, 127018 Россия Телефон: +7 (495) 780 48 20 Факс: +7 (495) 660 2330 Эл. адрес: [email protected] Сайт: http://www.CryptoPro.ru Сергей Е. Леонтьев (редактор) ООО «КРИПТО-ПРО» Сущевский вал, 16/5 Москва, 127018 Россия Телефон: +7 (495) 933 11 68 Факс: +7 (495) 933 11 68 Эл. адрес: [email protected] Сайт: http://www.CryptoPro.ru Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 16]