RFC 5652 Cryptographic Message Syntax (CMS)

Network Working Group                                         R. Housley
Request for Comments: 5652                                Vigil Security
Obsoletes: 3852                                           September 2009
Category: Standards Track

Синтаксис криптографических сообщений (CMS)

Cryptographic Message Syntax (CMS)

PDF

Тезисы

Данный документ описывает синтаксис криптографических сообщений (CMS1). Этот синтаксис применяется для цифровых подписей, дайджестов, проверки подлинности и шифрования произвольного содержимого сообщений.

Статус документа

Данный документ содержит спецификацию стандартного протокола Internet, предложенного сообществу Internet, и является приглашением к дискуссии в целях развития этого протокола. Сведения о текущем состоянии стандартизации протокола вы найдете в документе Internet Official Protocol Standards (STD 1). Документ можно распространять без ограничений.

Авторские права и лицензирование

Авторские права (Copyright (c) 2009) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Оглавление

Исключено в версии HTML.

1. Введение

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

CMS описывает синтаксис инкапсуляции, служащей для защиты данных. Этот синтаксис поддерживает шифрование и цифровые подписи. Возможна многократная инкапсуляция, когда инкапсулируемые данные уже являются инкапсуляцией других данных. Аналогично, может создаваться цифровая подпись для ранее инкапсулированных данных. Поддерживаются также произвольные атрибуты (например, время создания подписи), которые могут подписываться вместе с сообщением, обеспечивая привязку к подписи других атрибутов, типа заверяющей подписи (countersignature).

CMS может поддерживать множество вариантов архитектуры основанного на сертификатах распространения ключей (таких, как архитектура, разработанная группой PKIX2 [PROFILE]).

Значения CMS генерируются с применением нотации ASN.1 [X.208-88], использующей представление BER [X.209-88]. Значения обычно представляются в форме строк октетов. Хотя многие системы способны обеспечивать надежную передачу произвольных строк октетов, известно, что многие системы не обеспечивают этого. В этом документе не рассматриваются механизмы кодирования строк октетов для гарантированной передачи в подобных средах.

1.1. Развитие CMS

CMS происходит от PKCS #7 версии 1.5, документированной в RFC 2315 [PKCS#7]. PKCS #7 версии 1.5 была разработана без участия IETF и опубликована изначально как RSA Laboratories Technical Note в ноябре 1993 г. С этого момента ответственность за разработку и поддержку CMS перешла к IETF. В настоящее время несколько важных протоколов, стандартизируемых IETF, используют CMS.

В этом разделе описаны изменения, внесенные IETF в каждую из опубликованных версий CMS.

1.1.1. Отличия от PKCS #7 версии 1.5

RFC 2630 [CMS1] содержал первую версию CMS, включенную в процесс стандартизации IETF. Везде, где это было возможно, обеспечивалась совместимость с PKCS #7 версии 1.5, однако были внесены изменения для согласования с переносом сертификата атрибутов версии 1 и поддержки независимого от алгоритма управления ключами. PKCS #7 версии 1.5 включена только для поддержки транспортировки ключей. В RFC 2630 добавлена поддержка согласования ключей и методы шифрования с использованием заранее распространенных симметричных ключей.

1.1.2. Отличия от RFC 2630

RFC 3369 [CMS2] отменяет действие RFC 2630 [CMS1] и RFC 3211 [PWRI]. Управление ключами на основе паролей включено в спецификацию CMS и задан механизм расширения для поддержки новых схем управления ключами без внесения изменений в CMS. Совместимость со старыми версиями RFC 2630 и RFC 3211 сохранена, однако добавлен перенос сертификатов атрибутов версии 2, а применение сертификатов версии 1 запрещено.

Подписи S/MIME3 v2 [MSG2], основанные на PKCS#7 версии 1.5, совместимы с подписями S/MIME v3 [MSG3] и S/MIME v3.1 [MSG3.1]. Однако возникают незначительные проблемы совместимости с подписями на основе PKCS #7 версии 1.5. Эти вопросы рассматриваются в параграфе 5.2.1. Проблемы сохранились и в текущей версии CMS.

Конкретные криптографические алгоритмы не рассматриваются в этом документе, но они рассмотрены в RFC 2630. Обсуждение конкретных криптографических алгоритмов вынесено в отдельный документ [CMSALG]. Такое разделение позволяет IETF независимо обновлять каждый документ. Эта спецификация не требует реализации каких-либо конкретных алгоритмов. Вместо этого в CMS предполагается, что протоколы будут выбирать подходящие алгоритмы для работы в среде протокола. Эти алгоритмы могут выбираться из [CMSALG] или иных документов.

1.1.3. Отличия от RFC 3369

RFC 3852 [CMS3] отменяет действие RFC 3369 [CMS2]. Как отмечено в предыдущем параграфе, в RFC 3369 добавлен механизм расширения для поддержки схем управления ключами без внесения дополнительных изменений в CMS. RFC 3852 добавляет похожий механизм расширения для поддержки дополнительных форматов сертификатов и информации о статусе отзыва без внесения изменений в CMS. Эти расширения документированы в параграфах 10.2.1 и 10.2.2. Сохранена совместимость с предыдущими версиями CMS.

Использование номеров версий описано в параграфе 1.3.

С момента публикации RFC 3369 в документе был обнаружен ряд ошибок, указанных на сайте RFC Editor. В данном документе эти ошибки исправлены.

Прояснен текст параграфа 11.4, описывающего не подписанный атрибут countersignature. Будем надеяться, что новый текст более четко описывает часть подписи SignerInfo, которая покрывается countersignature.

1.1.4. Отличия от RFC 3852

Этот документ отменяет действие RFC 3852 [CMS3]. Основной причиной появления этого документа является продвижение CMS по пути стандартизации.

Этот документ включает разъяснения, которые были изначально опубликованы в RFC 4853 [CMSMSIG], в части обработки содержимого защищенного типа SignedData protected при наличии нескольких цифровых подписей.

С момента публикации RFC 3852 в документе был обнаружен ряд ошибок, указанных на сайте RFC Editor. В данном документе эти ошибки исправлены.

1.2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [STDWORDS].

1.3. Номера версий

Каждая из основных структур данных включает номер версии в качестве первого элемента структуры. Номера версий предназначены для предотвращения ошибок при декодировании ASN.1. Некоторые реализации не проверяют номер версии перед началом декодирования и только в случае возникновения ошибки просматривают этот номер в процессе обработки ошибочной ситуации. Это разумный подход, поскольку обработка ошибок осуществляется за пределами «быстрого пути». Такой подход также обеспечивает снисходительность к применению отправителями неверного номера версии.

Большинство исходных номеров версий было выделено в рамках PKCS #7 версии 1.5. Другие значения выделялись при определении соответствующих структур данных. При обновлении структур выделялось большее значение номера версии. Однако для обеспечения интероперабельности старший номер версии меняется лишь в случаях изменения синтаксиса. Т. е., выбирается наименьший номер версии, которая поддерживает используемый синтаксис.

2. Общий обзор

Синтаксис CMS является достаточно общим для поддержки разных типов содержимого сообщений. В этом документе для защиты содержимого определяется ContentInfo. Метод ContentInfo инкапсулирует один указанный тип содержимого, а этот тип может поддерживать дополнительную инкапсуляцию. В документе определены 6 типов содержимого — данные (data), подписанные данные (signed-data), вложенные данные (enveloped-data), данные с цифровой подписью (digested-data), шифрованные данные (encrypted-data) и аутентифицированные данные (authenticated-data). Дополнительные типы содержимого могут быть определены в других документах.

Реализация, соответствующая требованиям этого документа, должна реализовать ContentInfo, а также должна поддерживать типы data, signed-data и enveloped-data. Могут поддерживаться также другие типы содержимого.

В качестве общего подхода для каждого типа содержимого возможна однопроходная обработка и использованием представления BER4 с неопределенным размером. Однопроходные операции особенно хороши для содержимого большого размера, сохраняемого на лентах или получаемого от других процессов через «конвейер» (pipe). Однако такие операции имеют один существенный недостаток — для них сложно выполнить представление с использованием правил DER5 [X.509-88] в один проход, поскольку размеры различных компонент заранее могут быть не известны. Однако подписанные атрибуты в типе signed-data (подписанные данные) и аутентифицированные атрибуты в типе authenticated-data требуется передавать в формате DER, чтобы получатели могли проверить наличие в содержимом нераспознанных атрибутов. Из числа используемых в CMS атрибутов представление DER требуется только для подписанных и аутентифицированных атрибутов.

3. Базовый синтаксис

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

      id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }

CMS связывает идентификатор типа содержимого с самим содержимым. Синтаксис должен использовать тип ContentInfo в представлении ASN.1.

      ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

      ContentType ::= OBJECT IDENTIFIER

Смысл полей ContentInfo разъяснен ниже.

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

content представляет собой связанное с объектом содержимое. Тип содержимого может быть уникально определен из contentType. Типы содержимого для data, signed-data, enveloped-data, digested-data, encrypted-data и authenticated-data определены в настоящем документе. При определении в других документах дополнительных типов содержимого определяемому типу ASN.1 не следует быть типом CHOICE.

4. Тип содержимого data

Ниже приведен идентификатор типа содержимого data (данные).

      id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

Этот тип обозначает произвольную строку октетов (например, текст ASCII), интерпретация которой определяется приложением. Такие строки не обязаны иметь внутреннюю структуру (хотя и могут использовать свое определение ASN.1 или иную структуру).

S/MIME использует id-data для идентификации представленного в формате MIME содержимого. Использование этого идентификатора типа определено в RFC 2311 для S/MIME v2 [MSG2], RFC 2633 для S/MIME v3 [MSG3] и RFC 3851 для S/MIME v3.1 [MSG3.1].

Содержимое типа data обычно инкапсулируется в тип signed-data, enveloped-data, digested-data, encrypted-data или authenticated-data.

5. Тип содержимого Signed-data

Тип signed-data содержит данные любого типа и может включать значения цифровых подписей. Содержимое документа может подписать произвольное число лиц.

Типовым применением типа signed-data являются данные с цифровой подписью содержимого типа data. Другим вариантом применения этого типа является распространение сертификатов и списков отзыва сертификатов (CRL6).

Процесс создания типа signed-data включает несколько этапов, перечисленных ниже.

  1. Для каждого подписывающего лица рассчитывается значение цифровой подписи или хэш-сумма для содержимого с использованием специфического для данного подписывающего алгоритма. Если подписывается какая-либо информация кроме содержимого, создается цифровая подпись для содержимого и этой информации с использованием алгоритма подписывающего лица (см. параграф 5.4) и результат называется «отпечатком сообщения» (message digest).

  2. Для каждого подписывающего отпечаток сообщения подписывается с использованием секретного ключа подписывающего лица.

  3. Для каждого подписывающего лица значение подписи и другая специфическая для данного лица информация собираются в значение SignerInfo, как описано в параграфе 5.3. Сертификаты и списки CRL для каждого подписывающего, а также не соответствующие никому из подписавших собираются на этом этапе.

  4. Алгоритмы расчета отпечатков для всех подписавших, а также значения SignerInfo для них собираются в значение SignedData, как описано в параграфе 5.1.

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

При наличии множества подписей подтверждение пригодности одной подписи, связанной с данным лицом, обычно трактуется, как приемлемая подпись этого лица. Однако в некоторых прикладных средах требуются иные правила. Когда простого соответствия идентификатора подписавшего не достаточно для подтверждения создания подписи именно этим лицом, спецификация приложения должна указать способ определения подписей, которые были созданы данным лицом. Множество подписей одного лица включается прежде всего для поддержки различных групп (сообществ) получателей. Например, тип signed-data может включать подписи, созданные с использованием алгоритма RSA и алгоритма ECDSA7. Это позволяет получателям проверить подпись с помощью одного или другого алгоритма.

Этот раздел поделен на 6 частей, описывающих типы верхнего уровня SignedData, EncapsulatedContentInfo, SignerInfo для подписавшего, а также расчет отпечатка сообщения, генерацию подписи и ее проверку.

5.1. Тип SignedData

Приведенный ниже идентификатор указывает содержимое типа signed-data.

      id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

Тип signed-data должен иметь форму ASN.1 SignedData

      SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
        signerInfos SignerInfos }

      DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

      SignerInfos ::= SET OF SignerInfo

Значение полей типа SignedData описаны ниже.

version указывает номер версии синтаксиса. Набор допустимых значений определяется полями certificates, eContentType и SignerInfo. Значение version должно присваиваться по следующему алгоритму:

         IF ((имеется поле certificates) AND
            (присутствуют какие-либо сертификаты типа other)) OR
            ((присутствует crls) AND
            (присутствуют любые crls типа other))
         THEN version ДОЛЖНО иметь значение 5
         ELSE
            IF (имеется поле certificates) AND
               (присутствуют любые сертификаты атрибутов версии 2)
            THEN version ДОЛЖНО иметь значение 4
            ELSE
               IF ((имеется поле certificates) AND
                  ( присутствуют любые атрибуты сертификатов версии 1)) OR
                  (все структуры SignerInfo имеют версию 3) OR
                  (encapContentInfo eContentType отличается от id-data)
               THEN version ДОЛЖНО иметь значение 3
               ELSE version ДОЛЖНО иметь значение 1

 

digestAlgorithms — набор идентификаторов алгоритмов расчета отпечатка сообщения, который может содержать любое (включая 0) число элементов. Каждый элемент определяет алгоритм создания отпечатка (вместе со связанными с ним параметрами), используемого кем-либо из подписавших. Набор содержит список алгоритмов, используемых всеми подписавшими, в произвольном порядке для реализации однопроходной проверки подписей. Разработчики могут отказаться от проверки подписей, использующих алгоритмы, не включенные в список. Процесс создания отпечатков сообщений описан в параграфе 5.4.

encapContentInfo — подписанное содержимое, состоящее из идентификатора типа и собственно содержимого. Подробное описание типа EncapsulatedContentInfo приведено в параграфе 5.2.

certificates — набор сертификатов, включающий множество сертификатов, достаточное для поддержки путей сертификации от признанного «корня» (root) или агентства верхнего уровня (top-level certification authority) ко всем подписавшим из поля signerInfos. Набор может содержать избыточные сертификаты, а также может содержать сертификаты для поддержки путей к двум и более независимым агентствам верхнего уровня. Число сертификатов может быть меньше необходимого, если предполагается наличие у получателей других способов получения необходимых сертификатов (например, из предыдущего набора сертификатов). Могут включаться сертификаты подписавших. Использование сертификатов атрибутов версии 1 строго запрещено.

crls — набор информации о статусе отзывов. Предполагается, что этих данных предназначено для проверки пригодности сертификатов, указанных в поле certificates, но такое соответствие не является обязательным. Списки CRL являются первичным источником информации о статусе отзыва сертификатов. Поле может содержать избыточное число CRL, но может включать и недостаточное для проверки число списков.

SignerInfos представляет собой набор информации по каждому подписавшему. Эти данные могут содержать произвольное число элементов, включая 0. Когда набор включает более одной подписи, подтверждение пригодности одной подписи лица служит обозначением создания подписи этим лицом. Однако в некоторых прикладных средах могут потребоваться иные правила. Подробное описание типа SignerInfo приведено в параграфе 5.3. Поскольку каждый подписавший может применять свой метод цифровой подписи, а будущие спецификации могут менять синтаксис, все реализации должно корректно обрабатывать нереализованные версии SignerInfo. Более того, поскольку каждая реализация явно не может поддерживать все возможные алгоритмы цифровой подписи, все реализации должны корректно обрабатывать не поддерживаемые алгоритмы цифровой подписи, которые встречаются.

5.2. Тип EncapsulatedContentInfo

Тип EncapsulatedContentInfo имеет структуру

      EncapsulatedContentInfo ::= SEQUENCE {
        eContentType ContentType,
        eContent [0] EXPLICIT OCTET STRING OPTIONAL }

      ContentType ::= OBJECT IDENTIFIER

Поля EncapsulatedContentInfo описаны ниже.

eContentType — идентификатор объекта, уникально задающий тип содержимого.

eContent — собственно содержимое, передаваемое в виде строки октетов. Для eContent не требуется представление DER.

Поле eContent может отсутствовать в EncapsulatedContentInfo, что обеспечивает возможность создания «внешних подписей». В случае внешней подписи подписываемое содержимое отсутствует в EncapsulatedContentInfo, включаемом в тип signed-data. Если значение eContent отсутствует в EncapsulatedContentInfo, signatureValue рассчитывается и значение eContentType назначается как при наличии значения eContent.

В вырожденном случае отсутствия подписавших лиц значение EncapsulatedContentInfo не будет относиться к делу. В такой ситуации «подписываемый» тип содержимого в EncapsulatedContentInfo должен быть id-data (см. раздел 4), а поле содержимого в EncapsulatedContentInfo должно быть опущено.

5.2.1. Совместимость с PKCS #7

В этом параграфе приводится предупреждение для разработчиков, желающих поддерживать SignedData для типов данных CMS и PKCS #7 [PKCS#7] одновременно. Оба типа CMS и PKCS #7 указывают инкапсулированное содержимое с идентификатором объекта, но тип ASN.1 самого содержимого является переменным для PKCS #7 SignedData.

PKCS #7 определяет content как

      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

CMS определяет eContent как

      eContent [0] EXPLICIT OCTET STRING OPTIONAL

Определение CMS значительно проще в использовании для большинства приложений и совместимо с обоими форматами S/MIME v2 и S/MIME v3. Подписанные сообщения S/MIME, использующие CMS и PKCS #7, совместимы, поскольку форматы подписанных сообщений заданы идентично в RFC 2311 для S/MIME v2 [MSG2], RFC 2633 для S/MIME v3 [MSG3] и RFC 3851 для S/MIME v3.1 [MSG3.1]. S/MIME v2 инкапсулирует содержимое MIME в тип Data (строка октетов — OCTET STRING), передаваемые в SignedData contentInfo любого поля, а S/MIME v3 передает содержимое MIME в строке октетов SignedData encapContentInfo eContent. Следовательно, в S/MIME v2, S/MIME v3 и S/MIME v3.1 содержимое MIME помещается в OCTET STRING и отпечаток сообщения рассчитывается для идентичных частей содержимого. Т. е., отпечаток сообщения рассчитывается по октетам OCTET STRING без учета октетов тегов и размера.

Между типами CMS и PKCS #7 для SignedData имеется несовместимость, когда инкапсулированное содержимое не форматировано с использованием типа Data. Например, когда подписанная с использованием RFC 2634 [ESS] информация инкапсулируется в тип CMS SignedData, последовательность Receipt SEQUENCE представляется строкой октетов SignedData encapContentInfo eContent, а отпечаток сообщения рассчитывается с использованием всей последовательности Receipt (включая октеты тега, размера и значения). Однако, если подписанное в соответствии с RFC 2634 содержимое инкапсулируется в тип PKCS #7 SignedData, последовательность Receipt представляется в формате DER [X.509-88] SignedData contentInfo любого поля (SEQUENCE не является OCTET STRING). Следовательно, отпечаток сообщения рассчитывается только для октетов последовательности Receipt.

Показанный ниже метод может использоваться для обеспечения совместимости с PKCS #7 при обработке содержимого типа SignedData. Если реализаций не способна выполнить декодирование ASN.1 для типа SignedData, использующего синтаксис строки октетов CMS SignedData encapContentInfo eContent, она может попытаться декодировать тип SignedData используя синтаксис PKCS #7 SignedData contentInfo и рассчитывая соответствующим образом подпись сообщения.

Приведенный ниже метод может использоваться для обеспечения совместимости с PKCS #7 при создании содержимого типа SignedData, в котором инкапсулируемые данные не форматированы с применением типа Data. Реализация может проверить значение eContentType и подправить ожидаемое DER-представление eContent на основе значения идентификатора объекта. Например, для поддержки Microsoft Authenticode [MSAC] можно выполнить следующее:

eContentType Object Identifier устанавливается в { 1 3 6 1 4 1 311 2 1 4 }
eContent содержит информацию Authenticode в представлении DER.

5.3. Тип SignerInfo

Информация для каждого подписавшего представляется типом SignerInfo.

      SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

      SignerIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

      SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      Attribute ::= SEQUENCE {
        attrType OBJECT IDENTIFIER,
        attrValues SET OF AttributeValue }

      AttributeValue ::= ANY

      SignatureValue ::= OCTET STRING

Поля SignerInfo описаны ниже.

version — номер версии синтаксиса. Если в SignerIdentifier используется выбор (CHOICE) issuerAndSerialNumber, для номера версии должно устанавливаться значение 1. Если SignerIdentifier представляет собой subjectKeyIdentifier, должен устанавливаться номер версии 3.

sid указывает сертификат (и, следовательно, открытый ключ) подписавшего. Открытый ключ подписавшего требуется получателю для проверки подписи. SignerIdentifier обеспечивает два варианта указания открытого ключа подписавшего. Вариант issuerAndSerialNumber идентифицирует ключ по имени эмитента и порядковому номеру сертификата, вариант subjectKeyIdentifier — по идентификатору ключа. При указании сертификата X.509 идентификатор ключа соответствует значению расширения X.509 subjectKeyIdentifier. При указании других форматов документ, задающий формат и использование сертификата с CMS, должен включать детали идентификатора соответствующего ключа в подходящем поле сертификата. Реализации должны поддерживать восприятие форм issuerAndSerialNumber и subjectKeyIdentifier для SignerIdentifier. При генерации SignerIdentifier реализация может поддерживать лишь одну из этих форм (issuerAndSerialNumber или subjectKeyIdentifier) и всегда применять ее, а может также произвольно смешивать применение этих двух форм. Однако должен применяться идентификатор subjectKeyIdentifier для указания открытого ключа, содержащегося в сертификате, отличном от X.509.

digestAlgorithm идентифицирует алгоритм цифровой подписи сообщения и все связанные с ними параметры, использованные подписавшим. Отпечаток (подпись) сообщения рассчитывается для подписываемого содержимого или для содержимого вместе с атрибутами подписи, как описано в параграфе 5.4. Алгоритм подписи сообщения следует указывать в поле digestAlgorithms связанных с ним данных SignerData. Реализации могут отказываться от проверки подписей, использующих не включенный в SignedData digestAlgorithms алгоритм.

SignedAttrs представляет набор подписанных атрибутов. Поле является необязательным, но оно должно присутствовать, если подписываемое значение EncapsulatedContentInfo не является id-data. SignedAttributes должно представляться в формате DER даже при использовании для остальной структуры представления BER. Полезные типы атрибутов (такие, как время подписания) определены в разделе 11. Если данное поле присутствует, оно должно содержать по крайней мере два приведенных ниже атрибута:

content-type в качестве своего значения использует тип содержимого EncapsulatedContentInfo подписываемого значения. Атрибут content-type описан в параграфе 11.1. Однако атрибут content-type недопустимо применять как часть не подписанного атрибута countersignature, определенного в параграфе 11.4.

message-digest в качестве своего значения использует отпечаток сообщения для содержимого. Атрибут message-digest определен в параграфе 11.2.

signatureAlgorithm указывает алгоритм подписи и все связанные с ним параметры, использованные подписывающим при создании цифровой подписи.

signature — результат генерации цифровой подписи с использованием отпечатка сообщения и секретного ключа подписывающего. Детали подписи зависят от использованного алгоритма.

unsignedAttrs — набор атрибутов, которые не были подписаны. Это поле является необязательным. Полезные типы атрибутов (например, countersignatures) описаны в разделе 11.

Значения полей типов SignedAttribute и UnsignedAttribute описаны ниже.

attrType указывает тип атрибута и является идентификатором объекта.

attrValues указывает множество значений, составляющих атрибут. Тип каждого значения в этом множестве уникально определяется полем attrType (поле attrType может накладывать ограничения на число элементов множества).

5.4. Процесс расчета отпечатка сообщения

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

Результат процесса расчета отпечатка сообщения зависит от наличия поля signedAttrs. В отсутствие этого поля результатом будет просто отпечаток сообщения, как описано выше. Если же поле имеется, результатом будет отпечаток полного DER-представления значения SignedAttrs, содержащегося в поле signedAttrs. Поскольку значение SignedAttrs (при его наличии) должно содержать атрибуты content-type и message-digest, их значения также опосредованно включаются в результат. Атрибут content-type недопустимо включать в неподписанный атрибут countersignature, как описано в параграфе 11.4. При расчете отпечатка выполняется раздельное представление поля signedAttrs. Тег IMPLICIT [0] в signedAttrs не используется для представления DER и взамен применяется тег EXPLICIT SET OF. Т. е. в расчет должно включаться DER-представление тега EXPLICIT SET OF (а не IMPLICIT [0]) вместе с октетами размера и содержимого SignedAttributes.

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

Хотя строка октетов тега encapContentInfo eContent не включается в расчет отпечатка сообщения, ее можно защитить иными средствами. Октеты размера защищаются самой природой алгоритма цифровой подписи, поскольку практически невозможно найти два разных сообщения любого размера, которые будут давать одинаковые отпечатки.

5.5. Процесс создания подписи

Входные данные для процесса генерации подписи включают результат процесса создания отпечатка сообщения (message digest) и секретный ключ подписывающего. Детали процесса генерации подписи зависят от применяемого алгоритма. Идентификатор объекта вместе со всеми параметрами, задающими алгоритм, используемый подписывающим, передаются в поле signatureAlgorithm. Значение подписи, созданное подписывающим, должно представляться в форме строки октетов (OCTET STRING) и передаваться в поле signature.

5.6. Процесс проверки подписи

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

Получателю недопустимо полагаться на какие-либо значения отпечатка сообщения, рассчитанные его создателем. Если поле SignedData signerInfo включает signedAttributes, отпечаток содержимого сообщения должен быть рассчитан в соответствии с параграфом 5.4. Для того, чтобы подпись считалась действительной, рассчитанный отпечаток должен совпасть со значением атрибута messageDigest, включенным в поле signedAttributes структуры SignedData signerInfo.

Если SignedData signerInfo включает signedAttributes, значение атрибута content-type должно совпадать со значением SignedData encapContentInfo eContentType.

6. Тип содержимого Enveloped-data

Содержимое типа enveloped-data состоит из зашифрованных данных любого типа и зашифрованных ключей шифрования содержимого (encrypted content-encryption key) для одного или множества получателей. Комбинация шифрованного содержимого и шифрованного ключа шифрования содержимого для получателя представляет собой «цифровой конверт» (digital envelope) для данного получателя. Содержимое любого типа может быть упаковано в конверты для произвольного числа получателей с использованием любого из поддерживаемых методов управления ключами для каждого из получателей.

Типовым применением содержимого типа enveloped-data служит представление «цифровых конвертов» для одного или множества получателей с содержимым типа data или signed-data.

Этапы создания цифрового конверта enveloped-data перечислены ниже.

  1. Ключи шифрования содержимого для конкретного алгоритма генерируются случайным образом.

  2. Ключи шифрования содержимого шифруются для каждого получателя. Детали этого шифрования зависят от применяемого механизма управления ключами и поддерживаются четыре основных метода:

    key transport (доставка ключей) — ключ шифрования содержимого шифруется с помощью открытого ключа получателя;

    key agreement (согласование ключей) — используются открытый ключ получателя и секретный ключ отправителя для генерации симметричного ключа, который применяется для шифрования ключей шифрования содержимого;

    symmetric key-encryption keys (шифрование с симметричным ключом) — ключ шифрования содержимого шифруется с использованием заранее полученного симметричного ключа, известного и получателю;

    passwords (пароль) — ключ шифрования содержимого шифруется с помощью ключа, генерируемого из пароля и некого заранее известного сторонам секретного значения.

  3. Для каждого получателя зашифрованный ключ шифрования содержимого и другая информация для конкретного получателя собираются в значение RecipientInfo, как описано в параграфе 6.2.

  4. Содержимое шифруется с использованием ключа content-encryption. При этом в зависимости от применяемого ключа и алгоритма может потребоваться дополнение шифруемого содержимого для выравнивания по размеру блока шифрования (см. параграф 6.3).

  5. Значения RecipientInfo для всех получателей собираются вместе с зашифрованным содержимым в структуру EnvelopedData, описанную в параграфе 6.1.

Получатель открывает «цифровой конверт», расшифровывая один из ключей шифрования содержимого, с помощью которого далее расшифровывается само содержимое.

Далее рассматривается структура верхнего уровня EnvelopedData, а затем тип RecipientInfo с информацией для конкретного получателя, а также процессы расшифровки ключей шифрования содержимого и самого содержимого.

6.1. Тип EnvelopedData

Тип содержимого enveloped-data указывает идентификатор

      id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

Тип enveloped-data должен иметь форму ASN.1 EnvelopedData

      EnvelopedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

      OriginatorInfo ::= SEQUENCE {
        certs [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }

      RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

      EncryptedContentInfo ::= SEQUENCE {
        contentType ContentType,
        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
        encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

      EncryptedContent ::= OCTET STRING

      UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

Значения полей EnvelopedData описаны ниже.

version — номер версии синтаксиса. Значение зависит от полей originatorInfo, RecipientInfo и unprotectedAttrs и должно присваиваться по следующему алгоритму:

         IF (присутствует originatorInfo) AND
            ((присутствуют любые сертификаты типа other) OR
            (присутствуют любые crls типа other))
         THEN устанавливается version = 4
         ELSE
            IF ((присутствует originatorInfo) AND
               (присутствуют любые сертификаты атрибутов версии 2)) OR
               (любая из структур RecipientInfo включает pwri) OR
               (любая из структур RecipientInfo включает ori)
            THEN устанавливается version = 3
            ELSE
               IF (originatorInfo отсутствует) AND
                  (unprotectedAttrs отсутствует) AND
                  (все структуры RecipientInfo имеют версию 0)
               THEN устанавливается version = 0
               ELSE устанавливается version = 2

originatorInfo — необязательное поле с информацией инициаторе; поле включается только в тех случаях, когда этого требует алгоритм управления ключами. Поле может содержать сертификаты и списки CRL:

certs — набор сертификатов, который может содержать сертификаты инициатора, связанные с несколькими разными алгоритмами управления ключами. Поле certs может также содержать сертификаты атрибутов, связанные с инициатором. Сертификаты в certs предназначены для того, чтобы обеспечить всем получателям возможность построения пути от признаваемого корня (root) или удостоверяющего центра верхнего уровня (top-level certification authority). Однако certs может содержать избыточные сертификаты, позволяющие построить несколько путей для двух и более удостоверяющих центров. Возможна и нехватка сертификатов в поле certs, если у получателя имеются другие способы получения требуемых сертификатов (например, предшествующий набор сертификатов).

crls — набор списков отзыва сертификатов (CRL). Это поле содержит информацию, которой может быть достаточно для проверки действительности сертификатов, указанных в поле certs, но эта достаточность не требуется. Это поле может содержать избыточное или недостаточное число списков CRL.

recipientInfos — набор информации, предназначенной для конкретного получателя. В наборе должен присутствовать по крайней мере один элемент.

encryptedContentInfo — зашифрованное содержимое.

unprotectedAttrs — необязательный набор незашифрованных атрибутов. Полезные типы атрибутов определены в разделе 11.

Поля типа EncryptedContentInfo имеют приведенные ниже значения

contentType указывает тип содержимого.

contentEncryptionAlgorithm указывает алгоритм шифрования содержимого и все связанные с ним параметры, которые применяются при шифровании содержимого. Процесс шифрования содержимого описан в параграфе 6.3. Для всех получателей используются одни и те же алгоритм и ключ шифрования содержимого.

encryptedContent — результат шифрования содержимого. Это поле является необязательным и при его отсутствии шифрованное содержимое должно доставляться иным способом.

Поле recipientInfos размещается перед полем encryptedContentInfo, что позволяет обрабатывать значение EnvelopedData за один проход.

6.2. Тип RecipientInfo

Предназначенная для отдельного получателя информация представляется типом RecipientInfo. Формат RecipientInfo отличается для каждого из поддерживаемых методов управления ключами. Для каждого получателя одного зашифрованного содержимого можно применять любой из методов управления ключами. Во всех случаях зашифрованный ключ шифрования содержимого передается одному или множеству получателей.

Поскольку не каждая реализация будет поддерживать все возможные алгоритмы управления ключами, все реализации должны корректно обрабатывать нереализованные алгоритмы, которые могут встречаться. Например, если получателю приходит ключ шифрования содержимого, зашифрованный с использованием его открытого ключа RSA и RSA-OAEP8, а реализация поддерживает только RSA PKCS #1 v1.5, в ней должна быть реализована процедура корректного отказа.

Реализации должны поддерживать доставку ключей (key transport), согласование ключей (key agreement) и применение известных симметричных ключей, представленные ktri, kari и kekri, соответственно. Реализации могут поддерживать управление ключами на основе пароля, представляемое pwri. Реализации также могут поддерживать любой другой метод управления ключами, представляемый ori. Поскольку каждый получатель может использовать свой метод управления ключами, а будущие спецификации могут добавлять новые методы, все реализации должны корректно обрабатывать не реализованные в них варианты RecipientInfo CHOICE и должны корректно обрабатывать не реализованные версии поддерживаемых вариантов CHOICE, а также должны корректно обрабатывать неизвестные или не реализованные варианты ori.

      RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo,
        pwri [3] PasswordRecipientinfo,
        ori [4] OtherRecipientInfo }

      EncryptedKey ::= OCTET STRING

6.2.1. KeyTransRecipientInfo

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

      KeyTransRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 0 or 2
        rid RecipientIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }

      RecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

Поля типа KeyTransRecipientInfo описаны ниже.

version — номер версии синтаксиса. Если RecipientIdentifier представляет собой CHOICE issuerAndSerialNumber, номер версии должен иметь значение 0. Если RecipientIdentifier представляет собой subjectKeyIdentifier, номер версии должен быть 2.

rid указывает сертификат или ключ получателя, который отправитель применил для защиты ключа шифрования содержимого путем шифрования с помощью открытого ключа получателя. RecipientIdentifier поддерживает два варианта указания сертификата и, соответственно, открытого ключа получателя. Сертификат получателя должен содержать открытый ключ для транспортировки ключей. Следовательно, сертификат получателя X.509 версии 3, содержащий расширение использования ключей (key usage), должен иметь флаг keyEncipherment. Вариант issuerAndSerialNumber указывает сертификат получателя по отличительному имени эмитента и номеру сертификата, а subjectKeyIdentifier — по идентификатору ключа. При указании сертификата X.509 идентификатор ключа соответствует значению расширения X.509 subjectKeyIdentifier. При указании сертификатов иного формата документ, задающий формат сертификата и его использование с CMS, должен включать детали сопоставления идентификатора ключа с подходящим полем сертификата. На стороне получателя реализации должны поддерживать оба варианта указания сертификата получателя, на стороне отправителя должен поддерживаться хотя бы один из этих вариантов.

keyEncryptionAlgorithm указывает алгоритм шифрования ключа и все связанные с ним параметры, которые потребуются получателю для расшифровки ключа шифрования содержимого. Процесс шифрования ключей описан в параграфе 6.4.

encryptedKey — результат шифрования ключа шифрования содержимого для данного получателя.

6.2.2. KeyAgreeRecipientInfo

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

      KeyAgreeRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- всегда устанавливается значение 3
        originator [0] EXPLICIT OriginatorIdentifierOrKey,
        ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        recipientEncryptedKeys RecipientEncryptedKeys }

      OriginatorIdentifierOrKey ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier,
        originatorKey [1] OriginatorPublicKey }

      OriginatorPublicKey ::= SEQUENCE {
        algorithm AlgorithmIdentifier,
        publicKey BIT STRING }

      RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

      RecipientEncryptedKey ::= SEQUENCE {
        rid KeyAgreeRecipientIdentifier,
        encryptedKey EncryptedKey }

      KeyAgreeRecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        rKeyId [0] IMPLICIT RecipientKeyIdentifier }

      RecipientKeyIdentifier ::= SEQUENCE {
        subjectKeyIdentifier SubjectKeyIdentifier,
        date GeneralizedTime OPTIONAL,
        other OtherKeyAttribute OPTIONAL }

      SubjectKeyIdentifier ::= OCTET STRING

Поля типа KeyAgreeRecipientInfo описаны ниже.

version — номер версии синтаксиса. Всегда должен иметь значение 3.

originator представляет собой выбор (CHOICE) из трех вариантов указания открытого ключа отправителя для согласования ключей. Отправитель использует соответствующий секретный ключ и открытый ключ получателя для генерации парного ключа, с помощью которого шифруется ключ шифрования содержимого. Вариант issuerAndSerialNumber задает сертификат отправителя и, следовательно, его открытый ключ путем указания отличительного имени эмитента сертификата и порядкового номера сертификата. Вариант subjectKeyIdentifier указывает сертификат и ключ отправителя с помощью идентификатора ключа. Для сертификата X.509 идентификатор ключа соответствует значению расширения X.509 subjectKeyIdentifier. Для других форматов сертификата документ со спецификацией этого формата и его применения в CMS должен подробно описывать сопоставление идентификатора подходящему полю сертификата. Вариант originatorKey указывает идентификатор алгоритма и открытый ключ отправителя для согласования ключей. Этот метод обеспечивает анонимность инициатора, поскольку открытый ключ не сертифицируется. Реализации должны поддерживать все три варианта указания открытого ключа отправителя.

ukm является не обязательным. Для некоторых алгоритмов согласования ключей отправитель представляет ключевой материал UKM9, чтобы гарантировать создание нового ключа каждый раз при взаимодействии с тем же партнером. Реализации должны воспринимать последовательности KeyAgreeRecipientInfo, включающие поле ukm. Реализации, не поддерживающие алгоритмы согласования ключей с использованием UKM, должны аккуратно обрабатывать наличие UKM.

keyEncryptionAlgorithm указывает алгоритм шифрования ключа и все связанные с ним параметры, использованные для зашифровки ключа шифрования содержимого с помощью этого ключа. Процесс шифрования ключей описан в параграфе 6.4.

recipientEncryptedKeys включает идентификатор получателя и зашифрованный ключ для одного или множества получателей. KeyAgreeRecipientIdentifier представляет собой выбор (CHOICE) из двух вариантов задания сертификата получателя и, следовательно, его открытого ключа, который был использован отправителем для генерации парного ключа для зашифровки ключа шифрования содержимого. Сертификат получателя должен содержать открытый ключ, применяемый для согласования ключей. Следовательно, сертификат получателя X.509 версии 3 с расширением key usage должен иметь установленный бит keyAgreement. Ключ шифрования содержимого шифруется с использованием парного ключа. Вариант issuerAndSerialNumber указывает сертификат получателя по отличительному имени эмитента и порядковому номеру сертификата, тип RecipientKeyIdentifier описан ниже. encryptedKey представляет собой результат зашифровки ключа шифрования содержимого с помощью парного ключа, генерируемого с использованием алгоритма согласования ключей. Реализации должны поддерживать оба варианта указания сертификата получателя.

Поля типа RecipientKeyIdentifier описаны ниже.

subjectKeyIdentifier указывает сертификат получателя идентификатором ключа. При указании сертификата X.509 идентификатор ключа соответствует значению расширения X.509 subjectKeyIdentifier. Для других сертификатов документы со спецификацией формата и использования в CMS должны включать детали сопоставления идентификатора ключа подходящему полю сертификата.

date — необязательное поле, которое указывает получателю дату предшествующего распространения ключевого материала UKM, который был использован отправителем.

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

6.2.3. KEKRecipientInfo

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

      KEKRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 4
        kekid KEKIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }

      KEKIdentifier ::= SEQUENCE {
        keyIdentifier OCTET STRING,
        date GeneralizedTime OPTIONAL,
        other OtherKeyAttribute OPTIONAL }

Поля типа KEKRecipientInfo описаны ниже

version — номер версии синтаксиса. Всегда должен иметь значение 4.

kekid указывает симметричный ключ, которым зашифрован ключ шифрования содержимого, заранее переданнный отправителю и одному или множеству получателей.

keyEncryptionAlgorithm указывает алгоритм шифрования ключа и все связанные с ним параметры, которые нужны для расшифровки ключа шифрования содержимого. Процесс шифрования ключей описан в параграфе 6.4.

encryptedKey — результат зашифровки ключа шифрования содержимого с помощью симметричного ключа.

Поля типа KEKIdentifier описаны ниже.

keyIdentifier — указывает ключ шифрования ключей, который был заранее передан отправителю и одному или множеству получателей.

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

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

6.2.4. PasswordRecipientInfo

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

Тип PasswordRecipientInfo задан в RFC 3211 [PWRI]. Структура PasswordRecipientInfo приведена здесь лишь для полноты.

      PasswordRecipientInfo ::= SEQUENCE {
        version CMSVersion,   -- всегда устанавливается значение 0
        keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }

Поля типа PasswordRecipientInfo описаны ниже.

version — номер версии синтаксиса. Всегда должен иметь значение 0.

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

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

encryptedKey — результат зашифровки ключа шифрования содержимого с помощью ключа шифрования ключей.

6.2.5. OtherRecipientInfo

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

      OtherRecipientInfo ::= SEQUENCE {
        oriType OBJECT IDENTIFIER,
        oriValue ANY DEFINED BY oriType }

Поля типа OtherRecipientInfo описаны ниже.

oriType указывает метод управления ключами.

oriValue содержит элементы протокольных данных, требуемые получателю, который использует указанный метод управления ключами.

6.3. Процесс шифрования содержимого

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

В некоторых алгоритмах шифрования предполагается, что размер исходных данных кратен некому целому числу k, где k больше 1. Для таких алгоритмов к входным данным в конце будут добавляться октеты заполнения со значениями k — (lth mod k) в количестве k — (lth mod k), где lth — размер исходных данных. Иными словами, после исходных данных будут добавляться последовательности

                     01 -- если lth mod k = k-1
                  02 02 -- если lth mod k = k-2
                      .
                      .
                      .
            k k ... k k -- если lth mod k = 0

Октеты заполнения могут быть однозначно идентифицированы и удалены, включая ситуацию, когда исходные данные имеют размер, кратный величине блока и заполнения не используется. Этот метод заполнения корректно работает только в тех случаях, когда размер блока (k) меньше 256.

6.4. Процесс шифрования ключа

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

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

7. Тип содержимого Digested-data

Тип содержимого digested-data включает данные любого типа с отпечатком (message digest) для них.

Обычно тип digested-data используется для защиты целостности содержимого и результат процесса создания подписанных данных служит входной информацией для создания типа enveloped-data.

Создание типа digested-data включает два этапа:

  1. рассчитывается отпечаток (хэш) содержимого с использованием алгоритма message-digest;

  2. алгоритм message-digest и отпечаток сообщения вместе с подписанным содержимым объединяются в структуру DigestedData.

Получатель проверяет отпечаток сообщения, сравнивая полученное значение с рассчитанным им самим отпечатком.

Ниже приведен идентификатор объекта для содержимого типа digested-data.

      id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

Тип digested-data должен иметь форму ASN.1 DigestedData:

      DigestedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithm DigestAlgorithmIdentifier,
        encapContentInfo EncapsulatedContentInfo,
        digest Digest }

      Digest ::= OCTET STRING

Поля типа DigestedData описаны ниже.

version — номер версии синтаксиса. Если инкапсулировано содержимое типа id-data, для номера версии должно быть указано значение 0, однако для остальных типов должно устанавливаться значение 2.

digestAlgorithm — указывает алгоритм цифровой подписи и все связанные с ним параметры, использованные для создания подписи. Процесс создания цифровой подписи совпадает с описанным в параграфе 5.4, если не подписывается дополнительных атрибутов.

encapContentInfo — подписываемое содержимое, как определено в параграфе 5.2.

digest — результат процесса создания подписи для сообщения.

Порядок размещения полей digestAlgorithm, encapContentInfo и digest делает возможной обработку значения DigestedData за один проход.

8. Тип содержимого Encrypted-data

Тип encrypted-data содержит зашифрованные данные любого типа. В отличие от enveloped-data тип encrypted-data не включает ни получателей, ни зашифрованных ключей шифрования содержимого. Управление ключами должно осуществляться иным способом.

Типовым применением encrypted-data является шифрование содержимого для локального хранения (возможно, с генерацией ключа шифрования по паролю).

Ниже показан идентификатор объекта для содержимого типа encrypted-data.

      id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

Тип encrypted-data должен иметь форму ASN.1 EncryptedData

      EncryptedData ::= SEQUENCE {
        version CMSVersion,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

Поля типа EncryptedData описаны ниже

version — номер версии синтаксиса. При наличии unprotectedAttrs номер версии должен иметь значение 2, при отсутствии unprotectedAttrs должно указываться значение 0.

encryptedContentInfo — зашифрованное содержимое, как описано в параграфе 6.1.

unprotectedAttrs — набор атрибутов, которые не шифруются. Это поле не является обязательным. Полезные типы атрибутов определены в разделе 11.

9. Тип содержимого Authenticated-data

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

Процесс создания authenticated-data включает перечисленные ниже шаги.

  1. Случайным образом генерируется ключ аутентификации сообщения для конкретного алгоритма аутентификации.

  2. Ключ аутентификации сообщения шифруется для каждого получателя. Детали этого шифрования зависят от используемого алгоритма управления ключами.

  3. Для каждого получателя зашифрованный ключ аутентификации сообщения вместе с другой, относящейся к этому получателю, информацией собираются в значение RecipientInfo, как описано в параграфе 6.2.

  4. Используя ключ аутентификации сообщения, инициатор рассчитывает значение MAC для содержимого. Если инициатор в дополнение к содержимому сообщения аутентифицирует какую-либо информацию (см. параграф 9.2), рассчитывается отпечаток (подпись) для содержимого, а затем этот отпечаток и дополнительные данные аутентифицируются с использованием ключа аутентификации и результат служит значением MAC.

9.1. Тип AuthenticatedData

Ниже приведен идентификатор объекта для содержимого типа authenticated-data.

      id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }

Тип authenticated-data должен иметь форму ASN.1 AuthenticatedData.

      AuthenticatedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        macAlgorithm MessageAuthenticationCodeAlgorithm,
        digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
        encapContentInfo EncapsulatedContentInfo,
        authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
        mac MessageAuthenticationCode,
        unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }

      AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

      MessageAuthenticationCode ::= OCTET STRING

Поля типа AuthenticatedData описаны ниже.

version — номер версии синтаксиса. Значение version должно устанавливаться по приведенным ниже правилам

         IF (присутствует originatorInfo) AND
            ((присутствуют любые сертификаты типа other) OR
            (присутствуют любые crls типа other))
         THEN version = 3
         ELSE
            IF ((присутствует originatorInfo) AND
               (присутствуют любые сертификаты атрибутов версии 2))
            THEN version = 1
            ELSE version = 0

originatorInfo — необязательная информация об инициаторе. Параметр указывается лишь в тех случаях, когда этого требует механизм управления ключами. Поле может включать сертификаты, сертификаты атрибутов и CRL, как указано в параграфе 6.1.

recipientInfos — набор информации для получателей, как определено в параграфе 6.1. Набор должен включать не менее 1 элемента.

macAlgorithm — идентификатор, указывающий алгоритм MAC и все связанные с ним параметры, использованные инициатором. Размещение поля macAlgorithm облегчает обработку получателем за один проход.

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

encapContentInfo — аутентифицируемое содержимое, как определено в параграфе 5.2.

authAttrs — набор аутентифицируемых атрибутов. Структура authAttrs является необязательной, но она должна присутствовать, если тип содержимого для значения EncapsulatedContentInfo, которое аутентифицируется, отличается от id-data. При наличии поля authAttrs должно присутствовать также поле digestAlgorithm. Для структуры AuthAttributes должно использоваться представление DER, даже если остальная часть структуры задана в представлении BER. Полезные типы атрибутов определены в разделе 11. При наличии поля authAttrs оно должно содержать по крайней мере два перечисленных ниже атрибута:

content-type использует в качестве своего значения тип аутентифицируемого значения EncapsulatedContentInfo. Атрибут content-type определен в параграфе 11.1.

message-digest использует в качестве своего значения цифровую подпись (дайджест) содержимого. Атрибут message-digest определен в параграфе 11.2.

mac — код аутентификации сообщения.

unauthAttrs — необязательный набор атрибутов, которые не аутентифицируются. В настоящее время не определены неаутентифицированные атрибуты, а другие полезные атрибуты определены в разделе 11.

9.2. Генерация MAC

В процессе расчета MAC вычисляется код аутентификации сообщения (MAC) для аутентифицируемого содержимого или отпечатка аутентифицируемого содержимого вместе с аутентифицируемыми атрибутами инициатора.

Если поле authAttrs отсутствует, входными данными для процесса расчета MAC служит строка октетов encapContentInfo eContent. В расчете MAC используются только октеты строки eContent без учета октетов тега и размера. Это позволяет рассчитывать значение MAC для строк, размер которых не известен заранее процессу MAC.

При наличии поля authAttrs должны учитываться атрибуты content-type (параграф 11.1) и message-digest (параграф 11.2), а входной информацией для процесса расчета MAC служит DER-представление authAttrs. Для расчета цифровой подписи сообщения выполняется отдельное кодирование поля authAttrs. Тег IMPLICIT [2] в поле authAttrs не используется для представления DER, взамен его применяется тег EXPLICIT SET OF. Т. е. в расчет цифровой подписи вместо DER-представления тега IMPLICIT [2] включается представление тега SET OF вместе с октетами размера и содержимого authAttrs.

Процесс расчета цифровой подписи вычисляет отпечаток аутентифицируемого сообщения. Исходными данными для процесса является «значение» инкапсулированного содержимого, которое будет аутентифицироваться. А именно, входными данными служит строка октетов encapContentInfo eContent, к которой применяется процесс аутентификации. Алгоритм расчета цифровой подписи учитывает только значение encapContentInfo eContent без октетов тега и размера. Это позволяет рассчитать цифровую подпись для содержимого, размер которого не известен заранее. Хотя октеты тега и размера encapContentInfo eContent не включаются в расчет цифровой подписи, они защищаются другими средствами. Октеты размера защищаются самой природой алгоритма цифровой подписи, поскольку найти два варианта содержимого произвольного размера, которые имели бы одинаковые отпечатки, не представляется возможным.

Входные данные процесса расчета MAC включают определенные выше входные данные MAC и ключ аутентификации, передаваемый в структуре recipientInfo. Детали расчета MAC зависят от используемого алгоритма MAC (например, HMAC11). Идентификатор объекта вместе со всеми параметрами, определяющими использованный инициатором алгоритм MAC, передаются в поле macAlgorithm. Значение MAC, созданное инициатором, передается в форме строки октетов (OCTET STRING) в поле mac.

9.3. Проверка MAC

Входом для процесса проверки MAC служат входные данные (определяются на основе наличия или отсутствия поля authAttrs, как указано в параграфе 9.2) и ключ аутентификации, передаваемый в recipientInfo. Детали процесса проверки MAC зависят от используемого алгоритма MAC.

Получателю недопустимо опираться на любые значения MAC или цифровой подписи, рассчитанные инициатором. Содержимое аутентифицируется в соответствии с описанием параграфа 9.2. Если инициатор включил аутентифицируемые атрибуты, содержимое authAttrs аутентифицируется в соответствии с параграфом 9.2. Для того, чтобы аутентификация считалась пройденной, значение MAC, рассчитанное получателем, должно совпасть со значением поля mac. Аналогично для успешной аутентификации при наличии поля authAttrs значение цифровой подписи, рассчитанное получателем, должно совпадать со значением атрибута message-digest в authAttrs.

Если AuthenticatedData включает authAttrs, значение атрибута content-type должно соответствовать значению AuthenticatedData encapContentInfo eContentType.

10. Полезные типы

Этот раздел состоит из двух частей — в первой определены идентификаторы алгоритмов, а во второй другие полезные типы.

10.1. Типы идентификаторов алгоритма

10.1. Algorithm Identifier Types

Все идентификаторы алгоритмов используют один тип:

AlgorithmIdentifier — определение заимствовано из X.509 [X.509-88].

Для каждого типа алгоритма имеется множество вариантов.

10.1.1. DigestAlgorithmIdentifier

Тип DigestAlgorithmIdentifier указывает алгоритм message-digest, примерами могут служить алгоритмы SHA-1, MD2, MD5. Алгоритм message-digest отображает строку октетов (содержимое) в другую строку октетов (отпечаток).

      DigestAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.2. SignatureAlgorithmIdentifier

Тип SignatureAlgorithmIdentifier указывает алгоритм подписи и может также указывать алгоритм отпечатка (message digest). Примерами могут служить RSA, DSA, DSA с SHA-1, ECDSA и ECDSA с SHA-256. Алгоритм подписи поддерживает операции создания и проверки подписи. При генерации подписи используется отпечаток сообщения и секретный ключ подписывающего. При проверке подписи используется отпечаток сообщения и открытый ключ подписавшего для проверки пригодности полученной подписи. Выполняемая операция определяется контекстом.

      SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.3. KeyEncryptionAlgorithmIdentifier

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

Детали шифрования и расшифровки зависят от используемого алгоритма управления ключами. Поддерживаются доставка (key transport) и согласование (key agreement) ключей, заранее известные симметричные ключи и ключи, создаваемые из паролей.

      KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.4. ContentEncryptionAlgorithmIdentifier

Тип ContentEncryptionAlgorithmIdentifier указывает алгоритм шифрования содержимого (примерами могут служить Triple-DES и RC2). Алгоритм шифрования содержимого поддерживает операции шифрования и расшифровки. Операция шифрования отображает строку октетов (открытый текст) на другую строку октетов (шифрованный текст) с использованием ключа шифрования содержимого. Операция расшифровки выполняет обратное преобразование. Выбор операции определяется контекстом.

      ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.5. MessageAuthenticationCodeAlgorithm

Тип MessageAuthenticationCodeAlgorithm указывает алгоритм для кода аутентификации сообщения (MAC) — примерами могут служить DES-MAC и HMAC-SHA-1. Алгоритм MAC поддерживает операции создания и проверки кода, в которых используется один и тот же симметричный ключ. Выбор операции определяется контекстом.

      MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier

10.1.6. KeyDerivationAlgorithmIdentifier

Тип KeyDerivationAlgorithmIdentifier определен в RFC 3211 [PWRI] и здесь это определение повторено для полноты.

Алгоритм генерации производных ключей преобразует пароль или общий секрет в ключ шифрования ключей.

      KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier

10.2. Другие полезные типы

В этом параграфе определены типы, используемые в других разделах данного документа. Типы никак не упорядочены.

10.2.1. RevocationInfoChoices

Тип RevocationInfoChoices дает набор вариантов информации о статусе отзыва. Предполагается, что такой набор содержит информацию, достаточную для идентификации связанных с набором сертификатов и сертификатов атрибутов, которые отозваны. Однако в наборе может содержаться избыточная информация о статусе отзыва, а также набор может не включать всей требуемой информации. Списки отзыва сертификатов X.509 (CRL) [X.509-97] являются основным источником информации о статусе отзыва, но могут поддерживаться иные форматы такой информации. Обеспечивается вариант OtherRevocationInfoFormat для поддержки любых других форматов информации об отзыве без дополнительного изменения CMS. Например, с помощью OtherRevocationInfoFormat могут поддерживаться отзывы протокола OCSP12 [OCSP].

CertificateList может содержать список CRL, ARL13, Delta CRL или Attribute CRL. Все эти списки используют общий синтаксис.

Тип CertificateList указывает список отзыва сертификатов (CRL). Эти списки определены в X.509 [X.509-97] и заданы для использования в Internet документом RFC 5280 [PROFILE].

Ниже приведено определение CertificateList из X.509.

      RevocationInfoChoices ::= SET OF RevocationInfoChoice

      RevocationInfoChoice ::= CHOICE {
        crl CertificateList,
        other [1] IMPLICIT OtherRevocationInfoFormat }

      OtherRevocationInfoFormat ::= SEQUENCE {
        otherRevInfoFormat OBJECT IDENTIFIER,
        otherRevInfo ANY DEFINED BY otherRevInfoFormat }

10.2.2. CertificateChoices

Тип CertificateChoices задает расширенный сертификат PKCS #6 [PKCS#6], сертификат X.509, сертификат атрибута X.509 версии 1 (ACv1) [X.509-97], сертификат атрибута X.509 версии 2 (ACv2) [X.509-00] или сертификат иного формата. Расширенные сертификаты PKCS #6 считаются устаревшими и поддерживаются лишь для совместимости со старыми версиями, поэтому применять их не следует. Сертификаты ACv1 также являются устаревшими, включены лишь для совместимости со старыми версиями и применять их не следует. Профиль Internet для сертификатов X.509 задан в документе Internet X.509 Public Key Infrastructure: Certificate and CRL Profile [PROFILE], профиль для сертификатов ACv2 — в документе An Internet Attribute Certificate Profile for Authorization [ACPROFILE]. Вариант OtherCertificateFormat служит для поддержки других форматов сертификатов без изменения CMS.

Определение Certificate заимствовано из X.509.

Определения AttributeCertificate заимствованы из X.509-1997 и X.509-2000 — определение из X.509-1997 обозначено AttributeCertificateV1 (см. параграф 12.2), а определение из X.509-2000 — AttributeCertificateV2.

      CertificateChoices ::= CHOICE {
       certificate Certificate,
       extendedCertificate [0] IMPLICIT ExtendedCertificate, -- отменено
       v1AttrCert [1] IMPLICIT AttributeCertificateV1,       -- отменено
       v2AttrCert [2] IMPLICIT AttributeCertificateV2,
       other [3] IMPLICIT OtherCertificateFormat }

      OtherCertificateFormat ::= SEQUENCE {
        otherCertFormat OBJECT IDENTIFIER,
        otherCert ANY DEFINED BY otherCertFormat }

10.2.3. CertificateSet

Тип CertificateSet представляет набор сертификатов, достаточный для обеспечения «пути сертификации» (certification path) от «корня» или «удостоверяющего центра верхнего уровня» до всех сертификатов отправителя, с которыми связан данный набор. Однако набор может включать избыточные сертификаты, а также может содержать неполный их комплект.

Точное значение термина «путь сертификации» выходит за рамки данной спецификации. Однако [PROFILE] включает определения для сертификатов X.509. Некоторые приложения могут ограничивать сверху размер пути сертификации, а другие могут предъявлять те или иные требования к связям между субъектами и эмитентами в пути сертификации.

      CertificateSet ::= SET OF CertificateChoices

10.2.4. IssuerAndSerialNumber

Тип IssuerAndSerialNumber указывает сертификат и, таким образом, субъекта и его открытый ключ по отличительному имени (distinguished name) эмитента и порядковому номеру сертификата.

Определение поля Name заимствовано из X.501 [X.501-88], а поля CertificateSerialNumber — из X.509 [X.509-97].

      IssuerAndSerialNumber ::= SEQUENCE {
        issuer Name,
        serialNumber CertificateSerialNumber }

      CertificateSerialNumber ::= INTEGER

10.2.5. CMSVersion

Тип CMSVersion указывает номер версии синтаксиса для обеспечения совместимости с будущими версиями этой спецификации.

      CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }

10.2.6. UserKeyingMaterial

Тип UserKeyingMaterial указывает синтаксис для пользовательского ключевого материала (UKM14). Некоторым алгоритмам согласования ключей UKM требуется для генерации разных ключей в каждом случае согласования между данной парой сторон. Отправитель предоставляет UKM для использования с конкретным алгоритмом согласования ключей.

      UserKeyingMaterial ::= OCTET STRING

10.2.7. OtherKeyAttribute

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

      OtherKeyAttribute ::= SEQUENCE {
        keyAttrId OBJECT IDENTIFIER,
        keyAttr ANY DEFINED BY keyAttrId OPTIONAL }

11. Полезные атрибуты

В этом разделе определены атрибуты, которые могут использоваться с содержимым типов signed-data, enveloped-data, encrypted-data, authenticated-data. Синтаксис Attribute совместим с X.501 [X.501-88] и RFC 5280 [PROFILE]. Некоторые из описанных в этом разделе атрибутов были определены в PKCS #9 [PKCS#9], а другие — в предыдущей версии этой спецификации [CMS1]. Атрибуты перечислены без какого-либо упорядочения.

Из числа атрибутов, определенных в других документах, следует отметить спецификацию S/MIME версии 3.1 [MSG3.1] и расширенные средства защиты для S/MIME [ESS], которые включают также рекомендации по размещению этих атрибутов.

11.1. Тип содержимого

Атрибут content-type указывает тип содержимого ContentInfo в signed-data или authenticated-data. Атрибут content-type должен присутствовать при наличии подписанных атрибутов в signed-data или аутентифицированных атрибутов в authenticated-data. Значение атрибута content-type должно соответствовать значению encapContentInfo eContentType в signed-data или authenticated-data.

Атрибут content-type должен быть подписанным (signed) или аутентифицированным (authenticated) атрибутом, для него недопустимо быть неподписанным (unsigned), неаутентифицированным (unauthenticated) или незащищенным (unprotected) атрибутом.

Ниже приведен идентификатор объекта для атрибута content-type.

      id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

Значения атрибута content-type имеют тип ASN.1 ContentType

      ContentType ::= OBJECT IDENTIFIER

Хотя синтаксис определен, как SET OF AttributeValue, атрибут content-type должен иметь единственное значение, отсутствие или несколько экземпляров AttributeValue не допускается.

Синтаксис SignedAttributes и AuthAttributes определяет их как SET OF Attributes. В SignedAttributes поля signerInfo недопустимо включать множество экземпляров атрибута content-type. Аналогично, в AuthAttributes поля AuthenticatedData недопустимо включать множество экземпляров атрибута content-type.

11.2. Отпечаток сообщения

Тип атрибута message-digest задает отпечаток (message digest) строки октетов encapContentInfo eContent, подписанной в signed-data (см. параграф 5.4) или аутентифицированной в authenticated-data (см. параграф 9.2). Для signed-data отпечаток рассчитывается с использованием алгоритма хэширования подписывающей стороны. Для authenticated-data отпечаток рассчитывается с использованием алгоритма хэширования инициатора.

В signed-data тип атрибута message-digest должен присутствовать при наличии любых подписанных атрибутов. В authenticated-data тип атрибута message-digest должен присутствовать при наличии любых аутентифицированных атрибутов.

Атрибут message-digest должен быть подписанным (signed) или аутентифицированным (authenticated), недопустимо использование неподписанного (unsigned), неаутентифицированного (unauthenticated) или незащищенного (unprotected) атрибута.

Ниже приведен идентификатор объекта для атрибута message-digest.

      id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

Атрибут message-digest должен иметь тип ASN.1 MessageDigest

      MessageDigest ::= OCTET STRING

Атрибут message-digest должен иметь единственное значение, несмотря на то, что его синтаксис определен, как SET OF AttributeValue. Недопустимо отсутствие или наличие множества экземпляров AttributeValue.

Синтаксис SignedAttributes и AuthAttributes определяет их как SET OF Attributes. В SignedAttributes поля signerInfo недопустимо включать множество экземпляров атрибута message-digest. Аналогично, в AuthAttributes поля AuthenticatedData недопустимо включать множество экземпляров атрибута message-digest.

11.3. Время подписи

Атрибут signing-time указывает время, когда подписавший (предположительно) «поставил свою подпись». Этот атрибут предназначен для использования в signed-data.

Атрибут signing-time должен быть подписанным (signed) или аутентифицированным (authenticated), недопустимо использование неподписанного (unsigned), неаутентифицированного (unauthenticated) или незащищенного (unprotected) атрибута.

Ниже приведен идентификатор объекта для атрибута signing-time.

      id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

Значения атрибыта signing-time имеют тип ASN.1 SigningTime.

      SigningTime ::= Time

      Time ::= CHOICE {
        utcTime UTCTime,
        generalizedTime GeneralizedTime }

Примечание. Определение Time соответствует версии X.509 от 1997 года [X.509-97].

Даты между 1 января 1950 г. и 31 декабря 2049 г. (включительно) должны представляться в формате UTCTime. Даты до 1950 г. и после 2049 г. должны представляться в формате GeneralizedTime.

Значения UTCTime должны указываться по времени Coordinated Universal Time (ранее, гринвичское время — Greenwich Mean Time или GMT, а также время Zulu) и должны включать секунды (т. е., использовать формат YYMMDDHHMMSSZ), даже если число секунд равно 0. Полночь должна представляться в виде YYMMDD000000Z. Информация о столетии является неявной и должна определяться следующим образом:

при YY не меньше 50 значение года должно интерпретироваться, как 19YY;

при YY < 50 значение года должно интерпретироваться, как 20YY.

Значения GeneralizedTime должны представляться во времени Coordinated Universal Time и должны включать секунды (т. е., использовать формат YYYYMMDDHHMMSSZ), даже если число секунд равно 0. В значения GeneralizedTime недопустимо включать доли секунд.

Атрибут signing-time должен иметь единственное значение, несмотря на синтаксис определения SET OF AttributeValue. Недопустимо отсутствие или множество экземпляров AttributeValue.

Синтаксис SignedAttributes и AuthAttributes определяет их как SET OF Attributes. В SignedAttributes поля signerInfo недопустимо включать множество экземпляров атрибута signing-time. Аналогично, в AuthAttributes поля AuthenticatedData недопустимо включать множество экземпляров атрибута signing-time.

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

11.4. Заверяющая подпись

Тип атрибута countersignature указывает одну или множество подписей для строки октетов содержимого signature в значении SignerInfo для signed-data. Т. е., отпечаток сообщения рассчитывается для октетов, представляющих значение OCTET STRING, без октетов тега и размера. Таким образом, тип атрибута countersignature «заверяет» (еще раз подписывает) другую подпись.

Атрибут countersignature должен быть неподписанным (unsigned), недопустимо использование подписанных (signed), аутентифицированных (authenticated), неаутентифицированных (unauthenticated) и незащищенных (unprotected) атрибутов.

Ниже приведен идентификатор объекта для атрибута countersignature.

      id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }

Значения атрибута countersignature имеют тип ASN.1 Countersignature

      Countersignature ::= SignerInfo

Значения countersignature имеют такой же смысл, как значения SignerInfo для обычных подписей, за исключением отмеченных ниже различий.

  1. В поле signedAttributes недопустимо включать атрибут content-type — для заверяющих подписей нет типа содержимого.

  2. Поле signedAttributes должно включать атрибут message-digest, если в нем есть какие-либо другие атрибуты.

  3. Входными данными для процесса создания отпечатка сообщения являются октеты содержимого DER-представления поля signatureValue в значении SignerInfo, с которым связан атрибут.

Атрибут countersignature может иметь множество значений. Синтаксис определен, как SET OF AttributeValue и должен присутствовать хотя бы один экземпляр AttributeValue.

Синтаксис UnsignedAttributes определен, как SET OF Attributes. UnsignedAttributes в signerInfo может включать множество экземпляров атрибута countersignature.

Поскольку countersignature имеет тип SignerInfo, атрибут сам по себе может включать атрибут countersignature. Это позволяет создавать цепочки заверяющих подписей произвольной длины.

12. Модули ASN.1

В параграфе 12.1 приведен модуль ASN.1 для CMS, а в параграфе 12.2 — для сертификата атрибутов версии 1.

12.1. Модуль CMS ASN.1

   CryptographicMessageSyntax2004
     { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   -- Экспортируется все
   -- Типы и значения, определенные в этом модуле, экспортируются для использования 
   -- в других модулях ASN.1. Их могут применять для своих целей другие приложения.

   IMPORTS

     -- Импорт из RFC 5280 [PROFILE], Приложение A.1
           AlgorithmIdentifier, Certificate, CertificateList,
           CertificateSerialNumber, Name
              FROM PKIX1Explicit88
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                     mod(0) pkix1-explicit(18) }

     -- Импорт из RFC 3281 [ACPROFILE], Приложение B
           AttributeCertificate
              FROM PKIXAttributeCertificate
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                     mod(0) attribute-cert(12) }

     -- Импорт из Приложения B к данному документу
           AttributeCertificateV1
              FROM AttributeCertificateVersion1
                   { iso(1) member-body(2) us(840) rsadsi(113549)
                     pkcs(1) pkcs-9(9) smime(16) modules(0)
                     v1AttrCert(15) } ;

   -- Синтаксис криптографического сообщения

   ContentInfo ::= SEQUENCE {
     contentType ContentType,
     content [0] EXPLICIT ANY DEFINED BY contentType }

   ContentType ::= OBJECT IDENTIFIER

   SignedData ::= SEQUENCE {
     version CMSVersion,
     digestAlgorithms DigestAlgorithmIdentifiers,
     encapContentInfo EncapsulatedContentInfo,
     certificates [0] IMPLICIT CertificateSet OPTIONAL,
     crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
     signerInfos SignerInfos }

   DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

   SignerInfos ::= SET OF SignerInfo

   EncapsulatedContentInfo ::= SEQUENCE {
     eContentType ContentType,
     eContent [0] EXPLICIT OCTET STRING OPTIONAL }

   SignerInfo ::= SEQUENCE {
     version CMSVersion,
     sid SignerIdentifier,
     digestAlgorithm DigestAlgorithmIdentifier,
     signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
     signatureAlgorithm SignatureAlgorithmIdentifier,
     signature SignatureValue,
     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

   SignerIdentifier ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     subjectKeyIdentifier [0] SubjectKeyIdentifier }

   SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

   UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

   Attribute ::= SEQUENCE {
     attrType OBJECT IDENTIFIER,
     attrValues SET OF AttributeValue }

   AttributeValue ::= ANY

   SignatureValue ::= OCTET STRING

   EnvelopedData ::= SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo,
     unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

   OriginatorInfo ::= SEQUENCE {
     certs [0] IMPLICIT CertificateSet OPTIONAL,
     crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }

   RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

   EncryptedContentInfo ::= SEQUENCE {
     contentType ContentType,
     contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
     encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

   EncryptedContent ::= OCTET STRING

   UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

   RecipientInfo ::= CHOICE {
     ktri KeyTransRecipientInfo,
     kari [1] KeyAgreeRecipientInfo,
     kekri [2] KEKRecipientInfo,
     pwri [3] PasswordRecipientInfo,
     ori [4] OtherRecipientInfo }

   EncryptedKey ::= OCTET STRING

   KeyTransRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- всегда устанавливается значение 0 или 2
     rid RecipientIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

   RecipientIdentifier ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     subjectKeyIdentifier [0] SubjectKeyIdentifier }

   KeyAgreeRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- always set to 3
     originator [0] EXPLICIT OriginatorIdentifierOrKey,
     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     recipientEncryptedKeys RecipientEncryptedKeys }

   OriginatorIdentifierOrKey ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     subjectKeyIdentifier [0] SubjectKeyIdentifier,
     originatorKey [1] OriginatorPublicKey }

   OriginatorPublicKey ::= SEQUENCE {
     algorithm AlgorithmIdentifier,
     publicKey BIT STRING }

   RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

   RecipientEncryptedKey ::= SEQUENCE {
     rid KeyAgreeRecipientIdentifier,
     encryptedKey EncryptedKey }

   KeyAgreeRecipientIdentifier ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     rKeyId [0] IMPLICIT RecipientKeyIdentifier }

   RecipientKeyIdentifier ::= SEQUENCE {
     subjectKeyIdentifier SubjectKeyIdentifier,
     date GeneralizedTime OPTIONAL,
     other OtherKeyAttribute OPTIONAL }

   SubjectKeyIdentifier ::= OCTET STRING

   KEKRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- всегда устанавливается значение 4
     kekid KEKIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

   KEKIdentifier ::= SEQUENCE {
     keyIdentifier OCTET STRING,
     date GeneralizedTime OPTIONAL,
     other OtherKeyAttribute OPTIONAL }

   PasswordRecipientInfo ::= SEQUENCE {
     version CMSVersion,   -- always set to 0
     keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
                                OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

   OtherRecipientInfo ::= SEQUENCE {
     oriType OBJECT IDENTIFIER,
     oriValue ANY DEFINED BY oriType }

   DigestedData ::= SEQUENCE {
     version CMSVersion,
     digestAlgorithm DigestAlgorithmIdentifier,
     encapContentInfo EncapsulatedContentInfo,
     digest Digest }

   Digest ::= OCTET STRING

   EncryptedData ::= SEQUENCE {
     version CMSVersion,
     encryptedContentInfo EncryptedContentInfo,
     unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

   AuthenticatedData ::= SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     macAlgorithm MessageAuthenticationCodeAlgorithm,
     digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
     encapContentInfo EncapsulatedContentInfo,
     authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
     mac MessageAuthenticationCode,
     unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }

   AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

   UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

   MessageAuthenticationCode ::= OCTET STRING

   DigestAlgorithmIdentifier ::= AlgorithmIdentifier

   SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

   KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

   ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

   MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier

   KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier

   RevocationInfoChoices ::= SET OF RevocationInfoChoice

   RevocationInfoChoice ::= CHOICE {
     crl CertificateList,
     other [1] IMPLICIT OtherRevocationInfoFormat }

   OtherRevocationInfoFormat ::= SEQUENCE {
     otherRevInfoFormat OBJECT IDENTIFIER,
     otherRevInfo ANY DEFINED BY otherRevInfoFormat }

   CertificateChoices ::= CHOICE {
     certificate Certificate,
     extendedCertificate [0] IMPLICIT ExtendedCertificate,  -- отменено
     v1AttrCert [1] IMPLICIT AttributeCertificateV1,        -- отменено
     v2AttrCert [2] IMPLICIT AttributeCertificateV2,
     other [3] IMPLICIT OtherCertificateFormat }

   AttributeCertificateV2 ::= AttributeCertificate

   OtherCertificateFormat ::= SEQUENCE {
     otherCertFormat OBJECT IDENTIFIER,
     otherCert ANY DEFINED BY otherCertFormat }

   CertificateSet ::= SET OF CertificateChoices

   IssuerAndSerialNumber ::= SEQUENCE {
     issuer Name,
     serialNumber CertificateSerialNumber }

   CMSVersion ::= INTEGER  { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }

   UserKeyingMaterial ::= OCTET STRING

   OtherKeyAttribute ::= SEQUENCE {
     keyAttrId OBJECT IDENTIFIER,
     keyAttr ANY DEFINED BY keyAttrId OPTIONAL }

   -- Идентификаторы типа содержимого

   id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }

   id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

   id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

   id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

   id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

   id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }

   -- Атрибуты CMS

   MessageDigest ::= OCTET STRING

   SigningTime  ::= Time

   Time ::= CHOICE {
     utcTime UTCTime,
     generalTime GeneralizedTime }

   Countersignature ::= SignerInfo

   -- Идентификаторы атрибутов объекта

   id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

   id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

   id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

   id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }

   -- Obsolete Extended Certificate syntax from PKCS #6

   ExtendedCertificateOrCertificate ::= CHOICE {
     certificate Certificate,
     extendedCertificate [0] IMPLICIT ExtendedCertificate }

   ExtendedCertificate ::= SEQUENCE {
     extendedCertificateInfo ExtendedCertificateInfo,
     signatureAlgorithm SignatureAlgorithmIdentifier,
     signature Signature }

   ExtendedCertificateInfo ::= SEQUENCE {
     version CMSVersion,
     certificate Certificate,
     attributes UnauthAttributes }

   Signature ::= BIT STRING

   END -- для CryptographicMessageSyntax2004

12.2. Модуль ASN.1 для сертификата атрибутов версии 1.

   AttributeCertificateVersion1
       { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   -- Экспортируется все

   IMPORTS

     -- Импорт из RFC 5280 [PROFILE], Приложение A.1
           AlgorithmIdentifier, Attribute, CertificateSerialNumber,
           Extensions, UniqueIdentifier
              FROM PKIX1Explicit88
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                     mod(0) pkix1-explicit(18) }

     -- Импорт из RFC 5280 [PROFILE], Приложение A.2
           GeneralNames
              FROM PKIX1Implicit88
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                     mod(0) pkix1-implicit(19) }

     -- Импорт из RFC 3281 [ACPROFILE], Приложение B
           AttCertValidityPeriod, IssuerSerial
              FROM PKIXAttributeCertificate
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                     mod(0) attribute-cert(12) } ;

   -- Определения взяты из X.509-1997 [X.509-97], но используются другие имена
   -- в целях предотвращения конфликтов.

   AttributeCertificateV1 ::= SEQUENCE {
     acInfo AttributeCertificateInfoV1,
     signatureAlgorithm AlgorithmIdentifier,
     signature BIT STRING }

   AttributeCertificateInfoV1 ::= SEQUENCE {
     version AttCertVersionV1 DEFAULT v1,
     subject CHOICE {
       baseCertificateID [0] IssuerSerial,
         -- связано с сертификатом открытого ключа
       subjectName [1] GeneralNames },
         -- связано с именем
     issuer GeneralNames,
     signature AlgorithmIdentifier,
     serialNumber CertificateSerialNumber,
     attCertValidityPeriod AttCertValidityPeriod,
     attributes SEQUENCE OF Attribute,
     issuerUniqueID UniqueIdentifier OPTIONAL,
     extensions Extensions OPTIONAL }

   AttCertVersionV1 ::= INTEGER { v1(0) }

   END -- для AttributeCertificateVersion1

13. Литература

13.1. Нормативные документы

[ACPROFILE] Farrell, S. and R. Housley, «An Internet Attribute Certificate Profile for Authorization», RFC 3281, April 2002.

[PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008.

[STDWORDS] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.

[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), 1988.

[X.501-88] CCITT. Recommendation X.501: The Directory — Models, 1988.

[X.509-88] CCITT. Recommendation X.509: The Directory — Authentication Framework, 1988.

[X.509-97] ITU-T. Recommendation X.509: The Directory — Authentication Framework, 1997.

[X.509-00] ITU-T. Recommendation X.509: The Directory — Authentication Framework, 2000.

13.2. Дополнительная литература

[CMS1] Housley, R., «Cryptographic Message Syntax», RFC 2630, June 1999.

[CMS2] Housley, R., «Cryptographic Message Syntax (CMS)», RFC 3369, August 2002.

[CMS3] Housley, R., «Cryptographic Message Syntax (CMS)», RFC 3852, July 2004.

[CMSALG] Housley, R., «Cryptographic Message Syntax (CMS) Algorithms», RFC 3370, August 2002.

[CMSMSIG] Housley, R., «Cryptographic Message Syntax (CMS) Multiple Signer Clarification», RFC 4853, April 2007.

[DH-X9.42] Rescorla, E., «Diffie-Hellman Key Agreement Method», RFC 2631, June 1999.

[ESS] Hoffman, P., Ed., «Enhanced Security Services for S/MIME», RFC 2634, June 1999.

[MSAC] Microsoft Development Network (MSDN) Library, «Authenticode», April 2004 Release.

[MSG2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, «S/MIME Version 2 Message Specification», RFC 2311, March 1998.

[MSG3] Ramsdell, B., Ed., «S/MIME Version 3 Message Specification», RFC 2633, June 1999.

[MSG3.1] Ramsdell, B., Ed., «Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification», RFC 3851, July 2004.

[NEWPKCS#1] Kaliski, B. and J. Staddon, «PKCS #1: RSA Cryptography Specifications Version 2.0», RFC 2437, October 1998.

[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, «X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP», RFC 2560, June 1999.

[PKCS#1] Kaliski, B., «PKCS #1: RSA Encryption Version 1.5», RFC 2313, March 1998.

[PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5. November 1993.

[PKCS#7] Kaliski, B., «PKCS #7: Cryptographic Message Syntax Version 1.5», RFC 2315, March 1998.

[PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types, Version 1.1. November 1993.

[PWRI] Gutmann, P., «Password-based Encryption for CMS», RFC 3211, December 2001.

[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

14. Вопросы безопасности

Синтаксис криптографических сообщений обеспечивает способ цифровой подписи, создания отпечатков, шифрования и аутентификации данных.

Реализации должны обеспечивать защиту секретных ключей подписывающего. Утечка секретного ключа позволит злоумышленникам представиться другим лицом.

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

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

Метод управления ключами, используемый для распространения ключей аутентификации сообщений, сам по себе должен обеспечивать аутентификацию источников, поскольку в противном случае будут доставляться целостные сообщения из неизвестных источников. Алгоритмы RSA [PKCS#1[, [NEWPKCS#1] и Ephemeral-Static Diffie-Hellman [DH-X9.42] не обеспечивают требуемой аутентификации источников. Алгоритм Static-Static Diffie-Hellman [DH-X9.42] обеспечивает требуемую аутентификацию, когда ключи инициатора и получателя оба привязаны к приемлемой идентификации в сертификатах X.509.

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

Реализации должны генерировать случайные значения ключей шифрования содержимого, ключей аутентификации сообщений, векторов инициализации (IV) и заполнения. Генерация ключевых пар «открытый-секретный» также основана на случайных значениях. Использование некачественных генераторов псевдослучайных чисел (PRNG15) при создании криптографических ключей может приводить к снижению уровня или полной утрате защиты. Атакующему может оказаться гораздо проще воспроизвести среду PRNG, в которой создавались ключи, перебрав сравнительно небольшой набор вариантов, нежели использовать средства подбора (brute force) во всем пространстве возможных ключей. Генерация качественных случайных чисел достаточно сложна. В RFC 4086 [RANDOM] представлены важные рекомендации по решению таких задач.

При использовании алгоритмов согласования ключей или заранее известных ключей шифрования ключей, такие ключи служат для шифрования ключей, которые, в свою очередь, применяются для шифрования содержимого. Если для шифрования ключей и содержимого применяются разные алгоритмы, эффективный уровень защиты определяется наиболее слабым из этих двух алгоритмов. Если, например, содержимое шифруется с помощью алгоритма Triple-DES с использованием 168-битового ключа, а для ключа шифрования ключей применяется алгоритм RC2 с 40-битовым ключом, уровень защиты будет соответствовать 40-битовому ключу. Тривиальный поиск для определения 40-битового ключа RC2 позволит расшифровать ключ Triple-DES, который после этого может использоваться для расшифровки содержимого. Следовательно, разработчики должны гарантировать, что для шифрования ключей используется алгоритм не менее (а возможно и более) сильный, нежели для шифрования содержимого.

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

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

15. Благодарности

Этот документ включает результаты работы многих профессионалов. Автор отмечает значительный вклад всех членов рабочей группы IETF S/MIME. Отдельные благодарности Rich Ankney, Simon Blake-Wilson, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, Dave Solo, Paul Timmel и Sean Turner за поддержку с их стороны.

Спасибо Tim Polk за помощь в продвижении этой спецификации по пути стандартизации. Дополнительная благодарность Jan Vilhuber за внимательно чтение, которое привело в сообщению RFC Errata 1744.


Адрес автора

Russell Housley

Vigil Security, LLC

918 Spring Knoll Drive

Herndon, VA 20170

USA

EMail: housley@vigilsec.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Cryptographic Message Syntax.

2Public Key Infrastructure using X.509 — инфраструктура открытых ключей с использованием X.509.

3Secure/Multipurpose Internet Mail Extensions — защищенные/многоцелевые расширения электронной почты Internet.

4Basic Encoding Rules — базовые правила представления.

5Distinguished Encoding Rules — правила «изысканного» представления.

6Certificate revocation list.

7Elliptic Curve Digital Signature Algorithm — алгоритм цифровой подписи на основе эллиптической кривой.

8Optimal Asymmetric Encryption Padding.

9User Keying Material — пользовательский ключевой материал.

10Message authentication code.

11Hashed Message Authentication Code — хэшированный код аутентификации сообщения.

12Online Certificate Status Protocol — протокол интерактивной информации о статусе сертификата.

13Authority Revocation List — список отзыва УЦ.

14User keying material.

15Pseudo-random number generators.




RFC 5681 TCP Congestion Control

Network Working Group                                      M. Allman
Request for Comments: 5681                                 V. Paxson
Obsoletes: 2581                                                 ICSI
Category: Standards Track                                 E. Blanton
                                                   Purdue University
                                                      September 2009

 

Контроль насыщения в TCP

TCP Congestion Control

PDF

Тезисы

В этом документе определены 4 связанных между собой алгоритма контроля насыщения1 для протокола TCP — slow start2, congestion avoidance3, fast retransmit4 и fast recovery5. Кроме того, в документе указано, как протоколу TCP следует начинать передачу после сравнительно долгого периода бездействия, а также рассмотрены различные методы генерации подтверждений. Данный документ служит заменой RFC 2581.

Статус документа

Документ содержит спецификацию стандартного протокола для сообщества Internet и является приглашением к дискуссии в целях развития и совершенствования протокола. Сведения о стандартизации и состоянии данного протокола можно найти в документе Internet Official Protocol Standards (STD 1). Допускается свободное распространение данного документа.

Авторские права

Авторские права ((c) 2009) принадлежат IETF Trust и лицам, являющимся авторами документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Этот документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Оглавление

Исключено из версии HTML

1. Введение

В этом документе даны спецификации четырех алгоритмов контроля насыщения для протокола TCP [RFC793]: slow start, congestion avoidance, fast retransmit и fast recovery. Эти алгоритмы были опубликованы в документах [Jac88] и [Jac90]. Использование алгоритмов с протоколом TCP стандартизовано в [RFC1122].

Отметим, что в документе [Ste94] приводятся примеры реального использования описанных здесь алгоритмов, а [WS95] содержит пояснения к исходному коду реализации этих алгоритмов в BSD.

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

Этот документ отменяет действие [RFC2581], который, в свою очередь, отменил [RFC2001].

Глава данного документа 2 содержит определения используемых в документе терминов. В главе 3 приведены спецификации алгоритмов контроля насыщения. Глава 4 посвящена ситуациям, связанным с алгоритмами контроля насыщения, а в главе 5 обсуждаются вопросы безопасности.

Ключевые слова «MUST» (необходимо), «MUST NOT» (недопустимо), «REQUIRED» (требуется), «SHALL» (следует), «SHALL NOT» (не следует), «SHOULD» (следует), «SHOULD NOT» (не следует), «RECOMMENDED» (рекомендуется), «MAY» (возможно) и «OPTIONAL» (необязательно) в данном документе трактуются в соответствии с [Bra97].

2. Определения

В этой главе приводятся определения некоторых терминов, которые будут использованы в документе.

SEGMENT — сегмент

Сегментом является любой пакет данных или подтверждение TCP/IP.

SENDER MAXIMUM SEGMENT SIZE (SMSS) — максимальный размер сегмента для отправителя

SMSS представляет собой размер самого большого сегмента, который может быть передан отправителем. Это значение может определяться на основе максимального блока данных, передаваемого через сеть, алгоритма определения Path MTU [RFC1191, RFC4821], RMSS (см. следующее определение) и других факторов. Размер не включает заголовков и опций TCP/IP.

RECEIVER MAXIMUM SEGMENT SIZE (RMSS) — максимальный размер сегмента для получателя

RMSS — размер максимального сегмента, который желает принимать получатель. Это значение задается в опции MSS, передаваемой хостом при организации соединения. Если опция MSS при организации соединения не была задана, используется значение 536 байтов [RFC1122]. Размер не включает заголовков и опций TCP/IP.

FULL-SIZED SEGMENT — полноразмерный сегмент

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

RECEIVER WINDOW (rwnd) — размер окна принимающей стороны

Последнее анонсированное значение размера окна принимающей стороны.

CONGESTION WINDOW (cwnd) — размер окна насыщения

Переменная состояния TCP, которая ограничивает количество данных, разрешенных протоколу для передачи. В любой момент для TCP недопустима передача данных с порядковыми номерами, превышающими значение суммы наибольшего из подтвержденных порядковых номеров и меньшего из двух значений cwnd и rwnd.

INITIAL WINDOW (IW) — начальный размер окна

Начальным размером окна является размер окна насыщения отправителя после завершения трехэтапного согласования параметров.

LOSS WINDOW (LW) — размер окна потерь

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

RESTART WINDOW (RW) — размер окна перезапуска

Размер окна насыщения после того, как TCP возобновит передачу из состояния бездействия (для случая использования алгоритма slow start см. параграф 4.1).

FLIGHT SIZE — размер звена

Количество данных, которые уже переданы, но еще не подтверждены кумулятивно.

DUPLICATE ACKNOWLEDGMENT — дубликат подтверждения

Подтверждение считается «дубликатом» в описанных здесь алгоритмах, если (a) получатель ACK имеет остающиеся для передачи данные, (b) входящее подтверждение не содержит каких-либо данных, (c) оба флага SYN и FIN сброшены, (d) номер подтверждения равен или превышает значение наибольшего номера подтверждения, полученного в данном соединении (TCP.UNA из [RFC793]) и (e) анонсируемое во входящем подтверждении окно равно окну, анонсированному в последнем входящем подтверждении.

В дополнение к этому TCP, использующий селективные подтверждения (SACK6) [RFC2018, RFC2883], может применять информацию SACK для определения дубликатов подтверждений (содержит ли ACK ранее неизвестную информацию SACK).

3. Алгоритмы контроля насыщения

В этой главе определены четыре алгоритма контроля насыщения — slow start, congestion avoidance, fast retransmit и fast recovery, разработанные в [Jac88] и [Jac90]. В некоторых случаях для отправителя TCP предпочтительно быть более консервативным, нежели позволяют алгоритмы, но для TCP недопустимо быть более агрессивным, чем позволяют алгоритмы (т. е., недопустимо передавать данные, когда рассчитанное с помощью алгоритмов значение cwnd не разрешает передачу).

Отметим также, что описанные в этом документе алгоритмы расчитаны на использование потери пакетов в качестве индикации перегрузки (насыщения). Можно также использовать механизм явных уведомлений о насыщении (ECN7), описанный в [RFC3168].

3.1 Алгоритмы Slow Start и Congestion Avoidance

Алгоритмы замедленного старта (slow start) и предотвращения перегрузки (congestion avoidance) должны использоваться отправителем TCP для контроля за передачей в сеть остающихся неотправленными данных. Для реализации этих алгоритмов в состояние соединения TCP добавлены две переменных — размер окна насыщения (cwnd) — задаваемый на стороне отправителя предел для количества данных, которые отправитель может передать в сеть до получения подтверждения (ACK), и анонсируемое получателем окно (rwnd), которое определяет установленный на приемной стороне предел размера остающихся данных. Передачей управляет меньшее из двух значений cwnd и rwnd.

Еще одна переменная состояния ssthresh8 используется для определения момента, когда следует использовать алгоритм замедленного старта или предотвращения перегрузки в соответствии с приведенными ниже описаниями.

Начало передачи в сеть с неизвестными условиями требует от TCP достаточно медленной проверки сети с целью определения доступной «емкости» для того, чтобы избежать насыщения сети избыточным потоком данных. Алгоритм slow start используется для решения этой задачи на начальном этапе передачи или после восстановления в результате потери пакетов, обнаруженной с помощью таймера повторной передачи. Этот алгоритм служит также для запуска процесса ACK-синхронизации, который используется отправителем TCP для отправки данных в сети при использовании алгоритмов замедленного старта, предотвращения перегрузки и восстановления после потерь.

IW — начальное значение cwnd — должно устанавливаться с использованием приведенных рекомендаций для максимального значение:

   Если SMSS > 2190 байтов
      IW = 2 * SMSS байтов; недопустимо превышать размер 2 сегментов
   Если (SMSS > 1095 байтов) и (SMSS <= 2190 байтов)
      IW = 3 * SMSS байтов; недопустимо превышать размер 3 сегментов
   Если SMSS <= 1095 байтов
      IW = 4 * SMSS байтов; недопустимо превышать размер 4 сегментов

Как сказано в [RFC3390], на основании SYN/ACK и подтверждения SYN/ACK недопустимо увеличивать размер окна насыщения. Более того, даже при потере SYN или SYN/ACK начальный размер окна, используемый отправителем после корректно переданного SYN должен быть равен одному сегменту, содержащему не более SMSS байтов.

Детальное обоснование и обсуждение установки значения IW приведено в работе [RFC3390]9.

Когда начальное окно размером более 1 сегмента реализуется вместе с Path MTU Discovery [RFC1191] и обнаружено, что используемое значение MSS слишком велико, значение окна насыщения cwnd следует уменьшить для предотвращения «выброса» большого числа мелких сегментов. Конкртено значение cwnd следует уменьшать SHOULD на отношение старого размера сегмента к новому размеру сегмента.

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

Алгоритм замедленного старта используется в тех случаях, когда cwnd < ssthresh, а при cwnd > ssthresh применяется алгоритм предотвращения перегрузки. Если cwnd = ssthresh отправитель может использовать любой из этих алгоритмов.

При замедленном старте TCP увеличивает размер окна cwnd не более, чем на SMSS байтов для каждого пакета ACK, кумулятивно подтверждающего доставку новой порции данных. Замедленный старт завершается, когда размер окна насыщения cwnd превышает порог ssthresh (или становится равным этому порогу), а также при возникновении перегрузки. Хотя традиционные реализации TCP увеличивают cwnd ровно на SMSS байтов при получении ACK, подтверждающего новые данные, рекомендуется увеличивать значение cwnd, как показано в уравнении

cwnd += min (N, SMSS) (2)

где N — число ранее не подтвержденных байтов, подтверждаемых входящим ACK. Это уточнение является частью процедуры Appropriate Byte Counting10 [RFC3465] и обеспечивает устойчивость к некорректному поведению получателей, которые могут пытаться спровоцировать отправителя на искусственное повышение cwnd с использованием механизма ACK Division [SCWA99]. Этот способ воздействия заключается в том, что получатель передает для одного сегмента данных TCP множество сегментов ACK, каждый из которых подтверждает только часть данных. В этом случае реализация TCP, увеличивающая cwnd на SMSS для каждого такого ACK будет недопустимо повышать объем данных, отправляемых в сеть.

В процессе предотвращения перегрузки размер окна cwnd увеличивается на 1 полноразмерный сегмент за каждый период кругового обхода RTT11. Предотвращение насыщения продолжается до тех пор, пока насыщение наблюдается. Основными рекомендациями для увеличения cwnd при предотвращении перегрузки являются следующие:

  • можно увеличивать cwnd на SMSS байтов;
  • следует увеличивать cwnd в соответствии с уравнением (2) один раз за период RTT;
  • недопустимо увеличивать cwnd более, чем на SMSS байтов.

Отметим, что [RFC3465] разрешает увеличивать cwnd более, чем на SMSS байтов для входящих подтверждений в процессе замедленного старта в качестве экспериментов. Однако такое поведение недопустимо в качестве стандартного.

Рекомендуется увеличивать cwnd во время предотвращения перегрузки на число байтов, которые были подтверждены сегментами ACK для новых данных (недостатком этой рекомендации является необходимость поддержки дополнительной переменной состояния). Когда число подтвержденных данных достигает значения cwnd, последнее может быть увеличено на значение до SMSS байтов. Отметим, что в процесс предотвращения перегрузки недопустимо увеличивать размер окна насыщения более, чем на SMSS байтов за период RTT. Этот метод позволяет реализациям TCP увеличивать cwnd на 1 сегмент за период RTT в случаях задержки ACK и обеспечивает устойчивость к атакам Division.

Другим общепринятым способом, с помощью которого TCP может менять значение cwnd в процессе предотвращения перегрузки, является уравнение (3):

cwnd += SMSS*SMSS/cwnd (3)

Это изменение выполняется на каждый входящий сегмент ACK, который подтверждает новые данные. Уравнение (3) обеспечивает подходящее приближение для лежащего в основе принципа увеличения cwnd на 1 полноразмерный сегмент за период RTT (отметим, что для соединений, в которых получатель подтверждает каждый второй пакет, уравнение (3) обеспечивает менее агрессивное поведение — увеличение cwnd примерно на каждые два периода RTT).

Примечание для разработчиков. Поскольку в реализациях TCP обычно используется целочисленная арифметика, выражение (3) может не приводить к увеличению размера окна cwnd, когда окно насыщения очень велико (больше, чем SMSS*SMSS). Если выражение (3) дает нулевой результат, его следует «округлять» до 1 байта.

Примечание для разработчиков. В старых реализациях используется дополнительная положительная константа в правой части выражения (3). Такой подход некорректен и может вести к снижению производительности [RFC2525].

Примечание для разработчиков. Некоторые реализации поддерживают размер окна cwnd в байтах, а другие — в полноразмерных сегментах. В последнем случае использование выражения (3) становится затруднительным и может оказаться предпочтительным механизм, рассмотренный в предыдущем абзаце.

Когда отправитель TCP обнаруживает потерю сегмента с помощью таймера повтора передачи, для переменной ssthresh должно устанавливаться значение, не превышающее значение выражения 4:

ssthresh = max (FlightSize / 2, 2*SMSS) (4)

Как было отмечено выше, FlightSize показывает количество данных, которые еще находятся в сети (переданы, но не подтверждены).

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

Примечание для разработчиков. Легко ошибиться и использовать cwnd вместо FlightSize, что может в некоторых реализациях приводить к увеличению порога до значений, превышающих rwnd.

Более того, при возникновении тайм-аута (как указано в [RFC2988]) необходимо устанавливать для размера окна насыщения cwnd значение, не превышающее размер окна потерь LW12, которое равно 1 полноразмерному сегменту (независимо от значения IW). Следовательно, после повтора передачи отброшенного сегмента отправитель TCP использует замедленный старт для увеличения окна от 1 полноразмерного сегмента до нового значения ssthresh, после чего снова включается механизм предотвращения перегрузки.

Как показано в [FF96] и [RFC3782], основанное на замедленном старте восстановление после тайм-аута может приводить необоснованным повторам передачи, ведущей к дублированию подтверждений. Реакция на прием таких дубликатов ACK в реализациях TCP существенно различается. Этот документ не задает способа трактовки таких подтверждений, но здесь отмечается, что могут быть получены некоторые преимущества в результате проведения дополнительных исследований и спецификации такого поведения.

3.2 Алгоритмы Fast Retransmit и Fast Recovery

Получателю TCP следует незамедлительно передавать дубликат ACK при получении сегмента с нарушением порядка доставки. Это делается для того, чтобы с помощью пакета ACK информировать отправителя о том, что сегмент был получен с нарушением порядка и указать порядковый номер ожидаемого сегмента. С точки зрения отправителя дубликат ACK может быть вызван различными проблемами в сети. Во-первых, причиной может служить отбрасывание сегментов. В этом случае все сегменты после отброшенного будут порождать дубликаты ACK. Во-вторых, дубликаты ACK могут быть обусловлены нарушением порядка доставки сегментов (например, при доставке по разным путям [Pax97]). Наконец, причиной появления дубликатов ACK может быть репликация пакетов ACK или сегментов данных в сети. В дополнение к сказанному получателю TCP следует незамедлительно передавать подтверждение ACK при получении сегмента, который полностью или частично заполняет пропуски в порядковых номерах. Это позволит предоставить своевременную информацию отправителю, выполняющему восстановление после потери с использованием тайм-аута повторной передачи (retransmission timeout), быстрого повтора (fast retransmit) или улучшенного алгоритма восстановления (loss recovery), описанного в параграфе 4.3.

Отправителю TCP следует использовать алгоритм быстрого повтора для детектирования потери и исправления ошибки с использованием входящих дубликатов ACK. Алгоритм быстрого повтора использует прибытие 3 дубликатов ACK (как определено в параграфе 2, без каких-либо промежуточных сегментов ACK, вызывающих смещение SND.UNA), как индикацию потери сегмента. После получения 3 дубликатов ACK протокол TCP выполняет повторную передачу сегмента, который представляется потерянным, без ожидания завершения отсчета таймера повтора передачи.

После того, как алгоритм быстрого повтора передаст те данные, которые представляются включенными в отсутствующий сегмент, алгоритм «быстрого восстановления» (fast recovery) регулирует передачу новых данных, пока не будет получено подтверждение ACK, не являющееся дубликатом. Алгоритм замедленного старта не используется по той причине, что получение дубликатов ACK не только указывает на потерю сегмента, но и говорит о высокой вероятности того, что сегменты покинули сеть (хотя массированное дублирование сегментов в сети может сделать такое допущение некорректным). Иными словами, поскольку получатель может генерировать дубликат ACK только при получении сегмента, считается, что этот сегмент покинул сеть и находится в приемном буфере, более не потребляя ресурсов сети. Более того, поскольку «синхронизация» ACK сохраняется [Jac88], отправитель TCP может продолжать передачу новых сегментов (хотя и со сниженным значением cwnd).

Алгоритмы быстрого повтора и быстрого восстановления обычно реализуются вместе, как описано ниже.

  1. При получении отправителем первого и второго дубликата ACK TCP следует передать сегмент не переданных ранее данных в соответствии с [RFC3042] — эта возможность обеспечивается тем, что при анонсируемом получателем окне приема выполняется условие FlightSize cwnd + 2*SMSS и имеются новые данные для передачи. В дальнейшем отправителю TCP недопустимо изменять значение cwnd для отражения этих двух сегментов [RFC3042]. Отметим, что отправителям, использующим SACK [RFC2018], недопустимо передавать новые данные, пока входящие дубликаты подтверждений содержат новую информацию SACK.

  2. При получении третьего дубликата ACK TCP должен установить значение ssthresh, которое не превышает значения выражения (4). При использовании [RFC3042] ограниченную передачу дополнительных данных недопустимо учитывать в этом расчете.

  3. Потерянный сегмент, начиная с SND.UNA, должен быть передан заново, а для cwnd устанавливается значение ssthresh + 3*SMSS. Это искусственно «увеличивает» размер окна насыщения на число сегментов (три), которые покинули сеть и буферизованы получателем.

  4. Для каждого принятого дополнительного дубликата ACK (после третьего) значение cwnd должно увеличиваться на SMSS. Это искусственно увеличивает окно насыщения для того, чтобы отразить выход из сети дополнительных сегментов.

    Примечание. В работе [SCWA99] рассмотрена атака со стороны получателя, в которой отправителю передается множество фальшивых дубликатов ACK с целью расширения cwnd и соответствующего повышения скорости отправки с передающей стороны. TCP может, следовательно, ограничивать кратность расширения cwnd в процессе восстановления после потерь до числа остающихся в сети сегментов (или близкого значения).

    Примечание. Если расширенный механизм восстановления (типа описанного в параграфе 4.3) не используется, такое увеличение FlightSize может (в соответствии с уравнением (4)) вызывать незначительное расширение cwnd и ssthresh, поскольку несколько сегментов между SND.UNA и SND.NXT, предполагающиеся вышедшими из сети, по прежнему будут отражены в значении FlightSize.

  5. При наличии новых не переданных данных, если позволяет новое значение cwnd и анонсированное получателем окно, TCP следует передать 1*SMSS байтов ранее не передававшихся данных.

  6. При получении следующего пакета ACK, подтверждающего ранее не подтвержденные данные TCP должен установить cwnd = ssthresh (значение порога, заданное в п. 2). Это называется «уменьшением» размера окна насыщения.

    Этому пакету ACK следует быть подтверждением, вызванным повтором в п. 3 в течение одного периода RTT после повтора (хотя подтверждение может прийти быстрей при наличии существенного нарушения порядка доставки сегментов данных на приемной стороне). Кроме того, этому пакету ACK следует подтверждать все промежуточные сегменты, переданные между потерянным сегментом и получением третьего дубликата ACK, если ни один из этих сегментов не был потерян.

Примечание: Известно, что этот алгоритм в общем случае не обеспечивает достаточно эффективного восстановления при множественных потерях в одном «звене13» пакетов [FF96]. Решение этой проблемы описана в параграфе 4.3.

4. Дополнительные вопросы

4.1 Перезапуск соединения

Хорошо известной проблемой, связанной с описанными выше алгоритмами контроля насыщения TCP, является потенциальная возможность возникновения недопустимо высоких уровней трафика, передаваемого через соединение TCP после сравнительно долгого простоя. После завершения периода бездействия TCP не может использовать ACK-синхронизацию для передачи новых сегментов в сеть, поскольку все подтверждения ACK уже получены из сети. Следовательно, как было сказано ранее, TCP после продолжительного простоя потенциально может передать блок данных размером cwnd со скоростью среды. Кроме того, изменение условий в сети при продолжительном бездействии может сделать неточной оценку пропускной способности сети между двумя точками на основе cwnd.

Документ [Jac88] рекомендует использовать замедленный старт для восстановления передачи после сравнительно долгого простоя. Замедленный старт позволяет восстановить ACK-синхронизацию, как это делается на начальном этапе работы соединения. Этот механизм довольно широко распространен и работает следующим образом. Когда TCP не получает сегмент в течение времени, превышающего тайм-аут повторной передачи, размер окна насыщения cwnd уменьшается до значения RW14 перед началом передачи.

В данном стандарте мы определяем RW = min(IW,cwnd).

Использование принятого последним сегмента для решения вопроса об уменьшении cwnd не приводит к снижению размера окна насыщения cwnd в распространенном случае для продолжительных соединений HTTP [HTH98]. В таких случаях Web-сервер получает запрос до передачи данных Web-клиенту. Получение запроса ведет к отрицательному результату при проверке бездействия соединения и позволяет TCP начать передачу со значением cwnd, которое может оказаться недопустимо большим.

Поэтому протоколу TCP следует устанавливать перед началом передачи для окна cwnd значение, не превышающее RW, если протокол TCP не передавал данных в течение времени, превышающего тайм-аут повтора передачи.

4.2 Генерация подтверждений

На приемной стороне следует использовать алгоритм задержки подтверждений, описанный в [RFC1122]. При использовании этого алгоритма для получателя недопустима избыточная задержка генерации подтверждений. В частности, пакеты ACK следует генерировать по крайней мере для каждого второго полноразмерного сегмента и генерация подтверждения должна происходить в течение не более 500 мсек с момента доставки первого неподтвержденного пакета.

Требование, в соответствии с которым пакеты ACK следует генерировать по крайней мере для каждого второго полноразмерного пакета, в документе [RFC1122] указано в одном месте как следует, в в другом – как должно. Ввиду неоднозначности мы будет использовать трактовку следует. Подчеркнем также, что уровень следует означает, что разработчик может отказаться от выполнения этого требования лишь после тщательной оценки возможных последствий. Обсуждение проблем, связанных с невыполнением требования генерации подтверждений не реже, чем для каждого второго полноразмероного сегмента, приводится в параграфе Stretch ACK violation документа [RFC2525].

В некоторых случаях между отправителем и получателем может отсутствовать согласие по поводу того, что собой представляет полноразмерный сегмент. Реализация протокола считается совместимой с требованиями этого параграфа, если она передает по крайней мере одно подтверждение каждый раз по получении 2*RMSS байтов новых данных от отправителя (RMSS – максимальный размер сегмента, указанный получателем отправителю, или принятое по умолчанию значение 536 байтов [RFC1122], если получатель не указал опцию MSS при организации соединения). Отправитель может быть вынужден использовать сегменты меньшего, чем RMSS, размера в результате ограничения MTU, path MTU или воздействия иных факторов. В качестве примера рассмотрим случай, когда получатель анонсирует RMSS = X, но отправитель использует сегменты меньшего размера Y (Y < X) вследствие ограничения path MTU или значения MTU на стороне отправителя. Получатель будет генерировать подтверждения ACK более редко, если он будет дожидаться доставки 2*X перед генерацией ACK. Очевидно, что подтверждения для 2 сегментов по Y байтов передавались бы чаще. Следовательно, несмотря на то, что не определен специфический алгоритм, для получателя желательно попытаться предотвратить подобные ситуации (например, путем подтверждения каждого второго сегмента независимо от их размера). Повторим еще раз, что недопустима задержка передачи ACK более чем на 500 мсек в результате ожидания доставки второго полноразмерного сегмента.

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

Для получателя TCP недопустимо генерировать более одного подтверждения ACK для каждого входящего сегмента, если это подтверждение не является обновлением предлагаемого размера окна в тех случаях, когда принимающее приложение забирает новые данные [[RFC813] и стр. 42[RFC793].

4.3 Механизмы восстановления при потерях

Исследователями TCP было предложено и опубликовано в RFC множество алгоритмов восстановления при потере сегментов, повышающих эффективность работы алгоритмов fast retransmit и fast recovery. Некоторые из таких алгоритмов (например, [FF96], [MM96a], [MM96b] b [RFC3517]) основаны на использовании опции селективных подтверждений (SACK15) [RFC2018], а для других (например, [Hoe96], [FF96] и [RFC3782]) SACK не требуется. Алгоритмы, работающие без SACK, используют «частичные подтверждения16» (пакеты ACK, которые подтверждают новые данные, но не подтверждают пропущенные при наличии потерь) для включения механизма повтора передачи. Хотя данный документ не стандартизует ни один из алгоритмов, которые могут повышать эффективность fast retransmit/fast recovery, такие алгоритмы неявно разрешены, если они соответствуют общим принципам базовых алгоритмов, описанных выше.

Т. е., при обнаружении первой потери в окне для ssthresh должно быть установлено значение, не превышающее значение уравнения (4). Далее, пока все сегменты в окне данных не будут восстановлены, число сегментов, передаваемых в течение каждого периода RTT, должно быть не более половины от числа остававшихся на момент обнаружения потери сегментов. И, наконец, после успешной передачи всех потерянных сегментов в данном окне для параметра cwnd должно быть установлено значение, не превышающее ssthresh, и для дальнейшего увеличения cwnd должен использоваться механизм предотвращения перегрузки. Потери в двух последовательных окнах данных или потерю при повторе передачи следует трактовать как двухкратную индикацию насыщения и, следовательно, значения cwnd и ssthresh должны в таких случаях уменьшаться дважды.

Мы рекомендуем разработчикам реализаций TCP применять ту или иную форму улучшенного восстановления после потерь, способную справиться с множественными потерями в одном окне данных. Алгоритмы, описанные подробно в [RFC3782] и [RFC3517] соответствуют приведенным выше общим принципам. Отметим, что набор соответствующих общим принципам алгоритмов не исчерпывается двумя указанными, однако эта пара алгоритмов была проверена на практике и в настоящее время стандартизуется.

5. Вопросы безопасности

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

С учетом атак ACK division, описанных в [SCWA99], данная спецификация рекомендует увеличивать размер окна насыщения на основе числа байтов, недавно подтвержденных в каждом поступающем сегменте ACK вместо увеличения на постоянное значение при каждом поступлении сегмента ACK (как описано в параграфе 3.1).

Работа Internet в значительной степени основана на корректности реализации этих алгоритмов, обеспечивающих стабильность сети и предотвращение коллапса в результате насыщения. Атакующий может заставить конечные точки TCP отвечать более агрессивно на угрозу насыщения путем фабрикации избыточных дубликатов подтверждений или избыточных подтверждений для новых данных. Концептуально такая атака может привести к связанному с насыщением коллапсу для части сети.

6. Различия между RFC 2001 и RFC 2581

[RFC2001] был подвергнут существенной редакторской правке, не позволяющей, по сути, создать список различий между [RFC2001] и [RFC2581]. Целью подготовки [RFC2581] было не изменение рекомендаций, содержащихся в [RFC2001], а разъяснение вопросов, которые не были детально рассмотрены в [RFC2001]. В частности, [RFC2581] содержит рекомендации в части поведения соединений TCP после сравнительно долгого бездействия, а также спецификации и разъяснения по некоторым вопросам генерации TCP ACK. Кроме того, была вдвое (с одного сегмента до 2) увеличена верхняя граница начального размера окна насыщения.

7. Отличия от RFC 2581

Добавлено определение дубликатов подтверждений на основе определения, используемого в BSD TCP.

В документе указано, что поведение по отношению к дубликатам ACK после завершения отсчета таймера повторной передачи требует дальнейшего изучения и не задается явно в данном документе.

Изменены требования к начальному размеру окна, чтобы позволить больший размер17, стандартизованный в [RFC3390]. В дополнение к этому было детализировано поведение для случаев, когда значение начального размера окна оказывается слишком большим в результате определения Path MTU [RFC1191].

Изменены рекомендации по выбору начального значения порога ssthresh — указано, что его следует делать произвольно большим, взамен указанного в предыдущей версии «можно делать произвольно большим». Это сделано для обеспечения дополнительных рекомендаций разработчикам.

В процессе замедленного старта явно рекомендовано использование Appropriate Byte Counting [RFC3465] с L=1*SMSS. Метод увеличения cwnd, заданный в [RFC2581], по-прежнему явно допускается. Рекомендуется использовать подсчет байтов в процессе предотвращения перегрузки (congestion avoidance), хотя метод из [RFC2581] и другие безопасные методы остаются допустимыми.

Прояснена трактовка ssthresh при тайм-ауте повтора передачи. В частности, указано, что при первом повторе передачи данного сегмента для ssthresh должно устанавливаться значение, равное половине FlightSize, которое остается постоянным в случае дополнительных повторов передачи того же сегмента.

Разъяснено описание ускоренного повтора (fast retransmit) и ускоренного восстановления (fast recovery), а также рекомендовано применение ограниченной передачи18 [RFC3042].

Реализациям TCP можно ограничивать число дубликатов ACK, которые могут искусственно зывашать значение cwnd при восстановлении в случаях потери, числом сегментов, остающихся для передачи, с целью предотвращения атак на базе обманных подтверждений, описанных в [SCWA99].

Изменено значение окна при перезапуске (restart window) с IW на min(IW,cwnd). Такое поведение было отмечено в [RFC2581], как экспериментальное.

Разработчикам TCP рекомендовано реализовать улучшенный алгоритм восстановления при потере сегментов, соответствующий изложенным в этом документе принципам.

Обновлено рассмотрение вопросов безопасности с учетом атак ACK division и рекомендацией использовать подсчет байтов для предотвращения таких атак.

8. Благодарности

Основные алгоритмы, описанные здесь, разработал Van Jacobson [Jac88, Jac90]. В дополнение к ним совместно с Hari Balakrishnan и Sally Floyd был разработан алгоритм Limited Transmit19 [RFC3042]. Начальное значение окна насыщения, указанное в этом документе, получено в результате работы с Sally Floyd и Craig Partridge [RFC2414, RFC3390].

W. Richard (Рич) Stevens написал первую версию этого документа [RFC2001] и был соавтором второй версии [RFC2581]. В настоящем документе многие вопросы были разъяснены, благодаря вкладу Рича в понимание контроля насыщения TCP, а также его помощи по многим вопросам, относящимся к сетям.

Мы хотели бы подчеркнуть, что ответственность за недостатки и ошибки, встречающиеся в этом документа, лежит исключительно на авторах текущей версии.

Часть текста данного документа заимствована из книг «TCP/IP Illustrated, Volume 1: The Protocols» Ричарда Стивенса (W. Richard Stevens) (Addison-Wesley, 1994) и «TCP/IP Illustrated, Volume 2: The Implementation» Гери Райта (Gary R. Wright) и Ричарда Стивенса (Addison-Wesley, 1995). Этот материал включен с разрешения издательства Addison-Wesley.

Anil Agarwal, Steve Arden, Neal Cardwell, Noritoshi Demizu, Gorry Fairhurst, Kevin Fall, John Heffner, Alfred Hoenes, Sally Floyd, Reiner Ludwig, Matt Mathis, Craig Partridge и Joe Touch внесли множество полезных предложений.

9. Литература

9.1. Нормативные документы

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

9.2. Дополнительная литература

[CJ89] Chiu, D. and R. Jain, «Analysis of the Increase/Decrease Algorithms for Congestion Avoidance in Computer Networks»21, Journal of Computer Networks and ISDN Systems, vol. 17, no. 1, pp. 1-14, June 1989.

[FF96] Fall, K. and S. Floyd, «Simulation-based Comparisons of Tahoe, Reno and SACK TCP», Computer Communication Review, July 1996, ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.

[Hoe96] Hoe, J., «Improving the Start-up Behavior of a Congestion Control Scheme for TCP»22, In ACM SIGCOMM, August 1996.

[HTH98] Hughes, A., Touch, J., and J. Heidemann, «Issues in TCP Slow-Start Restart After Idle», Work in Progress, March 1998.

[Jac88] Jacobson, V., «Congestion Avoidance and Control», Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

[Jac90] Jacobson, V., «Modified TCP Congestion Avoidance Algorithm», end2end-interest mailing list, April 30, 1990. ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail.

[MM96a] Mathis, M. and J. Mahdavi, «Forward Acknowledgment: Refining TCP Congestion Control», Proceedings of SIGCOMM’96, August, 1996, Stanford, CA. Доступна по ссылке http://www.psc.edu/networking/papers/papers.html

[MM96b] Mathis, M. and J. Mahdavi, «TCP Rate-Halving with Bounding Parameters», Technical report. Доступна по ссылке http://www.psc.edu/networking/papers/FACKnotes/current.

[Pax97] Paxson, V., «End-to-End Internet Packet Dynamics»24, Proceedings of SIGCOMM ’97, Cannes, France, Sep. 1997.

[RFC813] Clark, D., «Window and Acknowledgement Strategy in TCP», RFC 813, July 1982.

[RFC2001] Stevens, W., «TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms», RFC 2001, January 1997.

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Selective Acknowledgment Options», RFC 20181, October 1996.

[RFC2414] Allman, M., Floyd, S., and C. Partridge, «Increasing TCP’s Initial Window», RFC 2414, September 1998.

[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J., and B. Volz, «Known TCP Implementation Problems», RFC 2525, March 1999.

[RFC2581] Allman, M., Paxson, V., and W. Stevens, «TCP Congestion Control», RFC 2581, April 1999.

[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, «An Extension to the Selective Acknowledgement (SACK) Option for TCP», RFC 2883, July 2000.

[RFC2988] Paxson, V. and M. Allman, «Computing TCP’s Retransmission Timer», RFC 2988, November 2000.

[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, «Enhancing TCP’s Loss Recovery Using Limited Transmit», RFC 3042, January 2001.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[RFC3390] Allman, M., Floyd, S., and C. Partridge, «Increasing TCP’s Initial Window», RFC 3390, October 2002.

[RFC3465] Allman, M., «TCP Congestion Control with Appropriate Byte Counting (ABC)», RFC 3465, February 2003.

[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, «A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP», RFC 3517, April 2003.

[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, «The NewReno Modification to TCP’s Fast Recovery Algorithm», RFC 3782, April 2004.

[RFC4821] Mathis, M. and J. Heffner, «Packetization Layer Path MTU Discovery», RFC 4821, March 2007.

[SCWA99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, «TCP Congestion Control With a Misbehaving Receiver»25, ACM Computer Communication Review, 29(5), October 1999.

[Ste94] Stevens, W., «TCP/IP Illustrated, Volume 1: The Protocols», Addison-Wesley, 1994.

[WS95] Wright, G. and W. Stevens, «TCP/IP Illustrated, Volume 2: The Implementation», Addison-Wesley, 1995.

Адреса авторов

Mark Allman

International Computer Science Institute (ICSI)

1947 Center Street

Suite 600

Berkeley, CA 94704-1198

Phone: +1 440 235 1792

EMail: mallman@icir.org

http://www.icir.org/mallman/

Vern Paxson

International Computer Science Institute (ICSI)

1947 Center Street

Suite 600

Berkeley, CA 94704-1198

Phone: +1 510/642-4274 x302

EMail: vern@icir.org

http://www.icir.org/vern/

Ethan Blanton

Purdue University Computer Sciences

305 North University Street

West Lafayette, IN 47907

EMail: eblanton@cs.purdue.edu

http://www.cs.purdue.edu/homes/eblanton/


Перевод на русский язык

Николай Малых

электронная почта: nmalykh@protocols.ru

сайт: http://www.nmalykh.org

1При переводе термина “congestion” термин “перегрузка” использовался наряду с термином “насыщение”. Прим. перев.

2Замедленный старт.

3Предотвращение насыщения.

4Ускорение повторной передачи.

5Ускоренное восстановление.

6Selective acknowledgment.

7Explicit Congestion Notification.

8Порог замедленного старта.

9В RFC Errata предложено дополнение этого абзаца, содержащее следующий текст: «Значение IW для случаев, когда 1095 < SMSS 2190 байтов, будет отличаться от рекомендаций [RFC3390]. Новое определение будет сохранять предшествующее значение cwnd, кратное SMSS, и предотвращать передачу неполных сегментов.». Прим. перев.

10Appropriate Byte Counting — подходящий учет байтов.

11Round-trip time.

12Loss window.

13Группа пакетов, одновременно находящихся в сети между отправителем и получателем. Прим. перев.

14Restart window – окно рестарта.

15TCP selective acknowledgment.

16Partial acknowledgment.

17Larger Initial Window.

18Строго говоря, явная рекомендация использования «» в документе отсутствует. В параграфе 3.2 лищь сказано: «При использовании [RFC3042] ограниченную передачу дополнительных данных недопустимо учитывать в этом расчете.». Прим. перев.

19Ограниченная передача.

21Эта статья доступна по ссылке http://pages.cs.wisc.edu/~suman/courses/740/papers/chiu89isdn.pdf. Прим. перев.

22Эта статья доступна по ссылке http://conferences.sigcomm.org/sigcomm/1996/papers/hoe.pdf. Прим. перев.

24Эта статья доступна по ссылке http://conferences.sigcomm.org/sigcomm/1997/papers/p086.pdf. Прим. перев.

25Эта статья доступна по ссылке http://www.cs.washington.edu/homes/tom/pubs/CCR99.pdf. Прим. перев.