RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)

Network Working Group                                      J. Schaad
Request for Comments: 4211                   Soaring Hawk Consulting
Obsoletes: 2511                                       September 2005
Category: Standards Track

Формат сообщений запроса сертификата (CRMF) для инфраструктуры открытых ключей Internet X.509

Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

В этом документе описаны синтаксис и семантика CRMF1. Этот синтаксис служит для передачи запросов сертификата в удостоверяющий центр (CA2), возможно через центр регистрации (RA3), с целью создания сертификата X.509. Запрос обычно включает открытый ключ и связанные с ним регистрационные данные. Документ не определяет протокол запроса сертификата.

Оглавление

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

 

1. Введение и терминология

Этот документ описывает формат сообщений CRMF. Объекты CRM4 используются в протоколах для передачи запросов удостоверяющим центрам (CA) и, возможно, регистрационным агентствам (RA) на создание сертификатов X.509. Запрос обычно включает открытый ключ и связанную с ним регистрационную информацию.

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

Запросы сертификатов могут подаваться агентствами RA, запрашивающими сертификаты от имени субъектов (Subject), удостоверяющими центрами CA, запрашивающими кросс-сертификаты у других CA, или непосредственно конечными объектами (EE6).

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

2. Обзор

Создание запроса сертификации включает перечисленные ниже этапы.

  1. Создается объект CertRequest, который может включать открытый ключ, часть или все имя субъекта, другие запрашиваемые поля сертификата и иную управляющую информацию, относящуюся к процессу регистрации. В зависимости от протокола CRP, эта информация может быть задана субъектом (Subject) и потенциально изменена агентством RA, а также может быть задана агентством RA на основе Subject или представленной субъектом документации.

  2. При необходимости рассчитывается доказательство обладания7 (секретный ключ, соответствующий открытому ключу, для которого запрашивается сертификат).

  3. Дополнительная регистрационная информация может объединяться со значением proof-of-possession и структурой CertRequest для формирования CertReqMessage. Дополнительная регистрационная информация может быть добавлена как субъектом, так и регистратором RA.

  4. Сообщение CertReqMessage передается с использованием защиты в удостоверяющий центр CA. Конкретные меры транспортной защиты определяются каждым протоколом CRP, соответствующим этому документу.

2.1. Отличия от RFC 2511

  1. Добавлен вводный раздел.

  2. Добавлена концепция CRP и языка, относящегося к протоколам CRP.

  3. В параграфе 6.2 обозначение regToken заменено на authenticator.

  4. Добавлено описание содержимого структуры EncryptedValue.

  5. Изменено имя и содержимое OID {id-regInfo 1}.

  6. Добавлена детализация содержимого различных структур, определенных в документе.

  7. Заменено Приложение A со ссылкой на [RFC2875]. Единственное отличие состоит в том, прежний текст указывал использование дополнительного имени (alt name) субъекта при пустом основном имени. Такое поведение невозможно для сертификатов CA, введенных с использованием PKIX. Однако будет полезно обновить RFC 2875 с учетом этого обстоятельства.

  8. Добавлено Приложение C, описывающее необходимость POP и возможные атаки на POP.8

  9. Поле pop в структуре CertReqMsg переименовано в popo для предотвращения путаницы между POP и pop.

  10. Использование структуры EncryptedValue отменено в пользу структуры EnvelopedData.

  11. Более подробно описано структурирование секретных ключей при их шифровании.

  12. Для POP в алгоритмах согласования ключей разрешено использование алгоритмов, отличных от DH.

3. Синтаксис CertReqMessage

Сообщение запроса сертификата состоит из запроса сертификата, необязательного поля доказательства обладания (proof-of-possession) и необязательного поля регистрационной информации.

   CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

   CertReqMsg ::= SEQUENCE {
      certReq   CertRequest,
      popo      ProofOfPossession  OPTIONAL,
      -- содержимое зависит от типа ключа
      regInfo   SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL
   }

Смысл полей CertReqMsg описан ниже.

certReq содержит шаблон запрашиваемого сертификата. Шаблон заполняется субъектом или от его имени. Не все поля шаблона обязательны для заполнения, более подробное описание приведено в разделе 5.

popo содержит значение, используемое для демонстрации того, что лицо (сущность), указанное для сертификата в качестве Subject, реально обладает соответствующим секретным ключом. Это поле меняется по структуре и содержимому в зависимости от алгоритма с открытым ключом и режима его использования (шифрование или подпись), как указывается в поле эмитируемого сертификата KeyUsage. Дополнительная информация приведена в разделе 4.

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

Информацию, относящуюся непосредственно к содержимому сертификата, следует включать в содержимое certReq. Однако включение в certReq дополнительного содержимого агентствами RA может привести к утрате корректности поля popo (в зависимости от используемого метода POP). Следовательно, данные, предназначенные для содержимого сертификата, можно включать в поле regInfo.

Упомянутые выше протоколы CRP отвечают за определение деталей, которые могут быть заданы в поле regInfo. Этот документ описывает один способ представления информации в этом поле, подробно описанный в Приложении A.

4. Доказательство обладания (POP)

Для того, чтобы предотвратить возможность некоторых атак (см. Приложение C) и позволить CA/RA проверять приемлемость привязки между субъектом и парой ключей, заданные здесь структуры управления PKI предоставляют субъекту возможность подтвердить свое владение (и возможность использования) секретным ключом, соответствующим открытому ключу, для которого запрашивается сертификат. Данный CRP свободен в выборе способа реализации POP (например, процедурные меры за пределами основного канала против сообщений CRMF в основной полосе) в своих сертификационных обменах. В данном CRP, агентства CA и RA свободны в выборе между обеспечиваемыми методами POP (т. е., это вопрос локальной политики RA/CA). CRP следует определить требуемые методы POP или указать механизм, с помощью которого клиенты могут определить поддерживаемые методы POP.

Любой протокол CRP, соответствующий данному документу, должен обеспечивать исполнение POP тем или иным способом. В настоящее время применяется множество протоколов без PKIX (например, различные протоколы электронной почты), которые явно не проверяют привязку между субъектом и секретным ключом. Пока нет работающих протоколов, которые проверяют такую привязку (для ключевых пар подписи, шифрования и согласования ключей) и существуют неоднозначности, нельзя полагаться на то, что привязка подтверждена CA/RA. Следовательно, нельзя достоверно узнать, является ли привязка открытого ключа в сертификате действительно корректной.

POP обеспечивается разными способами в зависимости от типа ключа, для которого запрошен сертификат. Если ключ может применяться с разными целями (например, ключ RSA для подписи и расшифровки), можно использовать любой из методов. Разработчики протоколов должны принимать во внимание возможность наличия аппаратных ограничений (например, секретный ключ может храниться в аппаратном токене).

Данная спецификация разрешает случаи, когда POP подтверждается агентством CA, RA или обоими. Некоторые политики требуют от CA проверки POP на момент эмиссии сертификата, а таких случаях агентство RA должно пересылать поля CertRequest и ProofOfPossession от конечного элемента в CA без изменений (в такой ситуации RA может проверить POP и отвергнуть запрос сертификата вместо его пересылки в CA). Если использование CA не требуется политикой для проверки POP, агентству RA следует переслать запрос конечного элемента и представленные подтверждения без каких-либо изменений в CA, как указано выше. Если это невозможно (например, если RA проверяет POP с использованием специальных каналов), RA использует элемент raVerified для подтверждения агентству CA факта проверки требуемого подтверждения. Если CA/RA использует отдельный канал (out-of-band) для проверки POP (например, физичекое представление созданных CA/RA секретных ключей), поле ProofOfPossession опускается.

   ProofOfPossession ::= CHOICE {
       raVerified        [0] NULL,
       signature         [1] POPOSigningKey,
       keyEncipherment   [2] POPOPrivKey,
       keyAgreement      [3] POPOPrivKey }

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

raVerified показывает, что агентство RA выполнило процедуру POP, требуемую для запроса сертификата. Это поле используется, если 1) CA не требует подключения себя к проверке POP и 2) RA требуется изменить содержимое поля certReq. Протоколы CRP должны обеспечивать для RA метод подписывания ProofOfPossession. Запрашивающему недопустимо устанавливать это поле, а RA/CA недопустмимо воспринимать ProofOfPossession, если запрашивающий установил это поле.

signature служит для выполнения процедуры POP с ключами подписи. Более подробное описание приведено в параграфе 4.1.

keyEncipherment служит для выполнения процедуры POP с ключами шифрования ключей (например, RSA). Более подробное описание приведено в параграфе 4.2.

keyAgreement служит для выполнения процедуры POP с ключами согласования ключей (например, DH). Более подробное описание приведено в параграфе 4.3.

4.1. POP для ключа подписи

POP для ключа подписи выполняется путем подписывания части данных, содержащих отождествление (identity), для которого нужен сертификат.

При выполнении процедуры POP для ключа подписи следует рассмотреть три указанных ниже случая.

  1. Субъект сертификата еще не организовал аутентифицированного отождествления в CA/RA, но имеет пароль и строку отождествления от CA/RA. В этом случае структура POPOSigningKeyInput будет заполняться с использованием publicKeyMAC для authInfo, а пароль и отождествление будут использоваться для расчета publicKeyMAC. Открытый ключ для запрашиваемого сертификата будет помещен в обе структуры POPOSigningKeyInput и Certificate Template. Поле подписи рассчитывается для DER-представления структуры POPOSigningKeyInput.

  2. CA/RA имеет аутентифицированное отождествление для субъекта сертификата, но запрашивающая сертификат сторона не указала это отождествление в запросе. В этом случае структура POPOSigningKeyInput заполняется с использованием sender для authInfo. Открытый ключ для запрашиваемого сертификата будет помещен в обе структуры POPOSigningKeyInput и Certificate Template. Поле подписи рассчитывается для DER-представления структуры POPOSigningKeyInput.

  3. Субъект сертификата поместил свое имя в структуру Certificate Template вместе с открытым ключом. В этом случае поле poposkInput структуры POPOSigningKey опускается. Поле подписи рассчитывается для DER-представления certReq9.

   POPOSigningKey ::= SEQUENCE {
       poposkInput         [0] POPOSigningKeyInput OPTIONAL,
       algorithmIdentifier     AlgorithmIdentifier,
       signature               BIT STRING }

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

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

algorithmIdentifier указывает алгоритм подписи и связанные с ним параметры, используемые для создания значения POP.

signature содержит создаваемое значение POP10. При наличии poposkInput подпись рассчитывается для DER-представления poposkInput., а при отсутствии для расчета используется DER-представления certReq.

   POPOSigningKeyInput ::= SEQUENCE {
       authInfo            CHOICE {
           sender              [0] GeneralName,
           -- используется только при наличии аутентифицированного отождествления
           -- для отправителя (например, DN из выданного ранее и действительного сертификата)
           publicKeyMAC        PKMACValue },
           -- испольуется при отсутствии для отправителя аутентифицированного GeneralName;
           -- publicKeyMAC содержит основанное на пароле значение MAC
           -- для DER-представления publicKey
       publicKey           SubjectPublicKeyInfo }  -- from CertTemplate

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

sender указывает аутентифицированное отождествление, которое заранее было организовано для субъекта.

publicKeyMAC содержит значение, рассчитываемое с помощью общего для CA/RA и запрашивающей стороны ключа.

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

   PKMACValue ::= SEQUENCE {
      algId  AlgorithmIdentifier,
      value  BIT STRING }

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

algId указывает алгоритм, применяемый для расчета значения MAC. Все реализации должны поддерживать алгоритм id-PasswordBasedMAC, более подробно описанных в параграфе 4.4.

value содержит рассчитанное значение MAC, которое вычисляется для DER-представления открытого ключа субъекта сертификата.

Агентство CA/RA идентифицирует общий секрет для использования путем просмотра 1) поля имени в запросе сертификата или 2) любого из значений regToken (параграф 6.1) и authToken (параграф 6.2).

4.2. POP ключа шифрования ключей

Процедура POP для ключа шифрования ключей выполняется одним из трех различающихся методов. Можно представить секретный (private) ключ в CA/RA, расшифровать зашифрованный вызов от CA/RA (прямой метод) или создать сертификат, который может быть возвращен в зашифрованном виде и возвращен в качестве отклика на вызов (непрямой метод).

   POPOPrivKey ::= CHOICE {
       thisMessage       [0] BIT STRING,   -- устарело
       subsequentMessage [1] SubsequentMessage,
       dhMAC             [2] BIT STRING,   -- устарело
       agreeMAC          [3] PKMACValue,
       encryptedKey      [4] EnvelopedData }
     -- для keyAgreement (исключительно) владение подтверждается в этом сообщении
     -- (которое содержит MAC (для DER-представления параметра certReq в
     -- CertReqMsg, который может включать subject и publicKey) на основе ключа,
     -- созданного из секретного ключа DH конечного элемента и открытого ключа DH
     -- агентства CA); значение dhMAC ДОЛЖНО рассчитываться в соответствии с RFC 2875 
     -- для статического подтверждения владения.

   SubsequentMessage ::= INTEGER {
       encrCert (0),
       challengeResp (1) }

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

thisMessage содержит зашифрованный секретный ключ, для которого выдается сертификат. Владение секретным ключом подтверждается его предоставлением в CA/RA. При подготовке первой спецификации это поле было описано некорректно. Правильным назначением этого поля является создание структуры EncryptedValue, в которой зашифрованное содержимое является секретным ключом, а сама структура EncryptedValue затем «оборачивается» (wrapped) в тип BIT STRING. От этого поля отказались в пользу encryptedKey.

subsequentMessage используется для индикации выполнения POP путем расшифровки сообщения от CA/RA и возврата результат. Тип сообщения для расшифровки указывается использованным значением (value).

encrCert указывает, что выданный сертификат будет возвращен в зашифрованном виде. Запрашивающий должен будет расшифровать сертификат и предъявить результат агентству CA/RA. Детали обеспечиваются протоколом CRP.

challengeResponse указывает, что от CA/RA запрашивающему было отправлено сообщение с вызовом. Детали этого сообщения и ответа на вызов обеспечиваются протоколом CRP.

dhMAC используется для ключей при согласовании Diffie-Hellman и содержит рассчитанное значение MAC, которое получается с использованием секретного ключа запрашивающего и открытого ключа CA/RA. От применения этого поля отказались в пользу agreeMAC (см. параграф 4.3).

agreeMAC используется для ключей согласования ключа и содержит рассчитанное значение MAC, которое получается с использованием секретного ключа запрашивающего и открытого ключа CA/RA (см. параграф 4.3).

macAlg указывает алгоритм, используемый для расчета значения MAC.

macValue содержит рассчитанное значение MAC.

encryptedKey содержит зашифрованный секретный ключ, соответствующий открытому ключу, для которого выдается сертификат, а также идентификационное значение для указания факта создания стороной, запрашивающей сертификат. Зашифрованное содержимое должно иметь тип id-ct-encKeyWithID.

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

4.2.1. Тип содержимого Private Key Info

Этот тип содержимого служит для 1) подтверждения владения секретными ключами и 2) депонирования секретных ключей (с использованием элемента управления options control, как описано в параграфе 6.4). Эта структура основана на структуре информации о секретном ключе из [PKCS8], но имеет одно преднамеренное отличие. Возможны атаки на агентов депонирования, если те расшифровывают секретные ключи, но не знают, кому принадлежит зашифрованный ключ. Атакующие может перехватить зашифрованный секретный ключ, создать на его основе запрос сертификата и затем запросить операцию восстановления секретного ключа.

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

      id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}

      EncKeyWithID ::= SEQUENCE {
        privateKey           PrivateKeyInfo,
        identifier CHOICE {
          string               UTF8String,
          generalName          GeneralName
        } OPTIONAL
      }

      PrivateKeyInfo ::= SEQUENCE {
         version                   INTEGER,
         privateKeyAlgorithm       AlgorithmIdentifier,
         privateKey                OCTET STRING,
         attributes                [0] IMPLICIT Attributes OPTIONAL
      }

   Attributes ::= SET OF Attribute

Ниже описаны поля структуры EncKeyWithID.

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

identifier содержит имя, которое агентство CA/RA может связать с запрашивающим. Обычно это часть любого имени субъекта, его дополнительное имя (из имеющегося сертификата или запроса сертификата) или текстовый маркер, известный запрашивающему и CA/RA11. Это поле должно присутствовать, если цель заключается в подтверждении владения секретным ключом. Поле следует включать, если предполагается архивирование ключа и его расшифровка агентом архивирования.

Ниже описаны поля структуры PrivatekeyInfo.

version должно иметь значение 0.

privateKeyAlgorithm содержит идентификатор объекта для секретного ключа.

privateKey строка октетов, содержащая секртеный ключ в формате, определяемом значением privateKeyAlgorithm.

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

4.2.2. Структуры секретных ключей

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

4.2.2.1. Ключи D-H

При создании структуры PrivateKeyInfo для ключа D-H применяются приведенные ниже правила.

  1. Поле privateKeyAlgorithm должно иметь значение id-dh-private-number. Параметр id-dh-private-number представляет собой значение DomainParameters (импорт из [PKIXALG]).

  2. Структура ASN для privateKey должна иметь форму

            DH-PrivateKey ::= INTEGER
  3. Поле attributes должно быть опущено.

4.2.2.2. Ключи DSA

При создании структуры PrivateKeyInfo для ключа DSA применяются приведенные ниже правила.

  1. Поле privateKeyAlgorithm должно иметь значение id-dsa. Параметрами id-dsa являются Dss-Parms (импорт из [PKIXALG]).

  2. Структура ASN для privateKey должна иметь форму

            DSA-PrivateKey ::= INTEGER
  3. Поле attributes должно быть опущено.

4.2.2.3. Ключи RSA

При создании структуры PrivateKeyInfo для ключа RSA применяются приведенные ниже правила.

  1. Поле privateKeyAlgorithm должно иметь значение rsaEncryption.

  2. Структура ASN для privateKey MUST должна быть RSAPrivateKey (определено в [PKCS1]).

  3. Поле attributes должно быть опущено.

4.2.3. Рекомендации для вызовов-откликов

Ниже приводятся рекомендации для разработчиков протоколов регистрации в части ожиданий по работе непрямого подтверждения владения (indirect proof-of-possession0 и о некоторых «подводных камнях» при создании сообщений для реализации этого метода POP.

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

  2. Отклик от сервера включает зашифрованное значение того или иного типа данных. Получение этого значения от сервера нужно аутентифицировать каким-либо способом. Спецификация должна включать детальное описание способа возврата этого значения для разных типов ключей. Для ключей RSA значение может быть указано, как шифруемое непосредственно с открытым ключом RSA, но такой подход не будет работать с ключом D-H, где требуется указать опосредованный механизм шифрования значения.

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

При выполнении непрямой процедуры POP настоятельно рекомендуется требовать идентификаторы транзакций и одноразовые значения nonce, что позволит 1) связать между собой разные сообщения процесса и 2) внести каждому элементу некоторые случайные элементы в процесс подтверждения идентификации.

4.3. POP для ключа согласования ключей

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

При использовании представленных выше прямых или опосредованных методов шифрования агентству CA/RA потребуется создавать для таких случаев эфемерный ключ, если параметры алгоритма шифрования CA/RA и запрашивающей стороны не совпадают.

Конечный объект может запросить MAC сертификата (используя полученный расчетным путем общий секрет) в качестве четвертого варианта выполнения POP. Этот вариант может использоваться только в тех случаях, когда CA/RA уже имеет сертификат, который относится к конечному объекту и субъект (Subject) сертификата может использовать параметры CA/RA.

Для алгоритма согласования ключей DH все реализации должны поддерживать статический механизм DH Proof-of-Possession. Подробное описание этого алгоритма приведено в разделе 3 of [RFC2875]. Следует подчеркнуть, что при пустом значении субъекта или эмитента сертификата взамен следует использовать его дополнительное имя.

4.4. Использование MAC на базе паролей

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

Идентификатор алгоритма и структура параметров для Password-Based MAC приведены ниже.

      id-PasswordBasedMAC OBJECT IDENTIFIER ::= { 1 2 840 113533 7 66 13}

      PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         iterationCount      INTEGER,
         mac                 AlgorithmIdentifier
         }12

Назначение полей PBMParameter13 описано ниже.

salt содержит случайное значение, используемое для расчета ключа в процессе MAC. Следует применять значения salt размером не менее 8 октетов (64 бита).

owf указывает алгоритм и связанные с ним параметры, используемые для расчета ключа в процессе MAC. Все реализации должны поддерживать алгоритм SHA-1.

iterationCount указывает число итераций хэширования в процессе расчета ключа и должно иметь значение не менее 100 (многие предлагают использовать не менее 1000 итераций). Компромисс здесь заключается в выборе между обеспечиваемым уровнем защиты от атак и временем, затрачиваемым сервером на обработку всех итераций при расчете паролей. Хэширование обычно считается «недорогой» операцией, но это допущение может стать ошибочным с новыми вариантами хэш-функций.

mac указывает алгоритм и связанные с ним параметры функции MAC. Все реализации должны поддерживать алгоритм HMAC-SHA1 [HMAC]. Всем реализациям следует также поддерживать DES-MAC и Triple-DES-MAC [PKCS11].

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

Входные данные:

pw — строка октетов, содержащая пользовательский пароль;

data — строка октетов, содержащая значение, для которого рассчитывается MAC;

Iter — счетчик итераций.

Выход:

MAC — строка октетов, содержащая полученное в результате значение MAC.

  1. создается случайное значение salt = S;

  2. salt добавляется в конец pw — K = pw || salt;

  3. вычисляется хэш от K — K = HASH(K);

  4. если Iter > 0, выполняется декрементирование (Iter = Iter — 1) и возврат к п. 3;

  5. Рассчитывается HMAC в соответствии с [HMAC]

    MAC = HASH( K XOR opad, HASH( K XOR ipad, data) )

    значения opad и ipad определены в [HMAC].

5. Синтаксис CertRequest

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

   CertRequest ::= SEQUENCE {
      certReqId     INTEGER,            -- ID для сопоставления запросов с откликами
      certTemplate  CertTemplate,       -- выбранные поля выпускаемого сертификата
      controls      Controls OPTIONAL } -- атрибуты, влияющие на выпуск сертификата

   CertTemplate ::= SEQUENCE {
      version      [0] Version               OPTIONAL,
      serialNumber [1] INTEGER               OPTIONAL,
      signingAlg   [2] AlgorithmIdentifier   OPTIONAL,
      issuer       [3] Name                  OPTIONAL,
      validity     [4] OptionalValidity      OPTIONAL,
      subject      [5] Name                  OPTIONAL,
      publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
      issuerUID    [7] UniqueIdentifier      OPTIONAL,
      subjectUID   [8] UniqueIdentifier      OPTIONAL,
      extensions   [9] Extensions            OPTIONAL }

   OptionalValidity ::= SEQUENCE {
      notBefore  [0] Time OPTIONAL,
      notAfter   [1] Time OPTIONAL } -– требуется наличие хотя бы одного

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

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

certReqId содержит целочисленное значение, используемое запросившей сертификат стороной для сопоставления запроса с откликом.

certTemplate содержит шаблон сертификата X.509. Запрашивающий указывает в этих полях конкретные желаемые значения. Более подробное описание полей приведено ниже.

controls содержит атрибуты, которые не являются частью сертификата, но контролируют контекст, в котором выпускается сертификат. Подробное описание элементов управления, определенных в этом документе, можно найти в разделе 6. В других документах могут определяться свои элементы управления. За спецификацию требуемых элементов управления отвечает протокол CRP.

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

version должно иметь значение 2, если версия указана; следует опускать это поле.

serialNumber должно опускаться; это значение выделяется агентством CA при создании сертификата.

signingAlg должно опускаться; это значение выделяется агентством CA при создании сертификата.

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

validity обычно опускается, но может применяться для запроса конкретных будущих дат начала и завершения срока действия сертификата. Наиболее часто это поле будет использоваться при кросс-сертификации для CA. В таких случаях в этом поле может выть указан срок действия имеющегося сертификата и тогда новый сертификат будет иметь такой же срок действия. Если поле validity присутствует, в нем должно быть задано хотя бы одно из двух следующих субполей:

notBefore указывает время начала действия сертификата, заданное по тем же правилам, которые применяются для notBefore в [PROFILE];

notAfter указывает время завершения действия сертификата, заданное по тем же правилам, которые применяются для notAfter в [PROFILE].

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

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

issuerUID должно быть опущено; это поле отменено в [PROFILE].

subjectUID должно быть опущено; это поле отменено в [PROFILE].

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

Агентству CA/RA разрешено менять значения любого поля, за исключением publicKey. Возвращенный сертификат должен быть проверен запрашивающим на предмет приемлемости установленных значений полей. Агентствам CA/RA следует по возможности применять шаблоны.

В некоторых случаях все поля шаблона могут быть опущены. Если генерация ключа происходила в CA/RA и отождествление было помещено в другое место (например, как в описанном ниже id-regCtrl-regToken), запрашивающему не требуется задавать какое-либо поля.

6. Синтаксис элементов управления

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

   Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

В этом документе определено несколько элементов управления — regToken (параграф 6.1), authenticator (параграф 6.2), pkiPublicationInfo (параграф 6.3), pkiArchiveOptions (параграф 6.4), oldCertID (параграф 6.5), protocolEncrKey (параграф 6.6). Каждый протокол CRP должен определять набор поддерживаемых им элементов управления. Дополнительные элементы могут определяться в других RFC или в самом протоколе CRP.

6.1. Элемент regToken

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

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

Элемент regToken используется только для инициализации конечного элемента в PKI, тогда как элемент authenticator (см. параграф 6.214) может применяться как для начального, так и для последующих запросов.

В некоторых вариантах применения элемент regToken может содержать символьную строку или численное значения (типа случайной величины). В последнем случае значение представляется в форме строки символов, соответствующей двоичному значению. В качестве кодировки для regToken нужно применять UTF8String.

   id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }

Без предварительного согласования между подписчиком и CA это значение будет содержать текстовое представление некого общего секрета. Если вместо этого используется значения, рассчитанное на основе общего секрета, предполагается, что протокол CRP определяет новый элемент управления для этого конкретного расчета.

6.2. Элемент authenticator

Элемент управления authenticator содержит информацию, используемую на постоянной основе для организации некриптографической проверки отождествления при коммуникациях с CA. Примерами могут служить девичья фамилия матери, последние четыре цифры номера социального страхования или другая информация, доступная подписчику и CA, хэш-значение такой информации или иные данные, созданные специально для этой цели. Значение для элемента authenticator может создаваться подписчиком или агентством CA.

В некоторых вариантах применения элемент authenticator может содержать символьную строку или численное значения (типа случайной величины). В последнем случае значение представляется в форме строки символов, соответствующей двоичному значению. В качестве кодировки для authenticator нужно применять UTF8String.

   id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }

При выборе между использованием элемента authenticator или regToken следует использовать приведенные ниже рекомендации. Если используется однократное значение, следует выбирать элемент regToken. Если значение предназначено для долговременного использования, следует выбирать элемент authenticator.

6.3. Элемент pkiPublicationInfo

Элемент pkiPublicationInfo обеспечивает подписчикам возможность влиять на публикацию сертификата агентством CA/RA. Этот элемент считается рекомендацией и CA/RA могут игнрировать его. Элемент определяется приведенным ниже OID и синтаксисом.

   id-regCtrl-pkiPublicationInfo  OBJECT IDENTIFIER ::= { id-regCtrl 3 }

   PKIPublicationInfo ::= SEQUENCE {
        action     INTEGER {
                     dontPublish (0),
                     pleasePublish (1) },
        pubInfos  SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }

   SinglePubInfo ::= SEQUENCE {
         pubMethod    INTEGER {
             dontCare    (0),
             x500        (1),
             web         (2),
             ldap        (3) },
         pubLocation  GeneralName OPTIONAL }

Ниже описано назначение полей структуры PKIPublicationInfo.

action показывает желание или нежелание запрашивающей стороны публикации сертификата агентством CA/RA. Возможны значения приведены ниже15:

dontPublish говорит о желании запрашивающего отказаться от публикации сертификата (это может говорить о намерении опубликовать сертификат самостоятельно). При использовании значения dontPublish поле pubInfos должно быть опущено.

pleasePublish говорит о желании запрашивающего опубликовать сертификат через агентство CA/RA.

pubInfos указывает место, где запрашивающий желает опубликовать сертификат с помощью CA/RA. Это поле опускается при выборе запрашивающим опции dontPublish. Если запрашивающий хочет задать некие места публикации сертификата и позволяет CA/RA публиковать его в других местах, он будет указывать в структуре SinglePubInfo множество значений, одним из которых является dontCare.

Ниже описано назначение полей структуры SinglePubInfo.

pubMethod указывает тип адреса места, куда запрашивающий желает поместить сертификат с участием CA/RA.

dontCare показывает, что CA/RA может публиковать сертификат в любом месте по своему выбору. При указании dontCare поле pubLocation16 должно быть опущено.

x500 показывает желание запрашивающего опубликовать сертификат с помощью CA/RA в указанном месте. Место публикации задается полем x500 в структуре pubLocation.

ldap показывает желание запрашивающего опубликовать сертификат с помощью CA/RA в указанном месте. Место публикации задается полем ldap в структуре pubLocation.

web показывает желание запрашивающего опубликовать сертификат с помощью CA/RA в указанном месте. Место публикации задается полем http в структуре pubLocation.

pubLocation содержит адрес, по которому будет публиковаться сертификат. Выбор значения поля GeneralName определяется значением pubMethod в этой структуре.

Места для публикации могут указываться в любом порядке. Все указанные места обрабатываются CA в целях публикации.

6.4. Элемент pkiArchiveOptions

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

   id-regCtrl-pkiArchiveOptions   OBJECT IDENTIFIER ::= { id-regCtrl 4 }

   PKIArchiveOptions ::= CHOICE {
      encryptedPrivKey     [0] EncryptedKey,
      -- актуальное значение секретного ключа
      keyGenParameters     [1] KeyGenParameters,
      -- параметры, позволяющие заново сгенерировать секретный ключ
      archiveRemGenPrivKey [2] BOOLEAN }
      -- устанавливается значение TRUE, если отправитель хочет, чтобы получатель
      -- архивировал секретный ключ пары, которую он генерирует в ответ на данный запрос;
      -- FALSE, если архивирование нежелательно.

   EncryptedKey ::= CHOICE {
      encryptedValue        EncryptedValue, -- deprecated
      envelopedData     [0] EnvelopedData }
      -- зашифрованный секретный ключ ДОЛЖЕН помещаться в строку октетов
      -- envelopedData encryptedContentInfo encryptedContent.

   EncryptedValue ::= SEQUENCE {
      intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
      -- предусмотренный алгоритм, с которым будет использоваться значение
      symmAlg       [1] AlgorithmIdentifier  OPTIONAL,
      -- симметричный алгоритм шифрования значения
      encSymmKey    [2] BIT STRING           OPTIONAL,
      -- (зашифрованный) симметричный ключ шифрования значения
      keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
      -- алгоритм для шифрования симметричного ключа
      valueHint     [4] OCTET STRING         OPTIONAL,
      -- краткое описание или идентификатор содержимого encValue 
      -- (может быть осмысленным только для передающей стороны и применяться лишь
      -- в тех случаях, когда EncryptedValue можно перепроверить в будущем 
      -- на передающей стороне)
      encValue       BIT STRING }
   -- От применения поля EncryptedValue отказались в пользу структуры EnvelopedData.
   --
   -- При использовании EncryptedValue для передачи секретного ключа (в отличие от
   -- сертификата), реализация ДОЛЖНА поддерживать поле encValue, содержащее
   -- зашифрованное значение PrivateKeyInfo как указано в параграфе 12.11 [PKCS11].
   -- Если encValue содержит иной формат/кодирование секретного ключа, первый октет
   -- valueHint МОЖЕТ применяться для индикации этого формата/кодирования (отметим,
   -- что возможные значения этого октета в настоящее время не заданы). В любом случае
   -- поле intendedAlg ДОЛЖНО использоваться для индикации хотя бы идентификатора OID
   -- предусмотренного алгоритма секретного ключа, если он не известен заранее отправителю
   -- и получателю.

   KeyGenParameters ::= OCTET STRING

Ниже описано назначение полей структуры PKIArchiveOptions.

encryptedPrivKey содержит зашифрованную версию секретного ключа.

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

archiveRemGenPrivKey показывает желание запрашивающего архивировать ключ, создаваемый агентством CA/RA от имени запрашивающего.

Ниже описано назначение полей структуры EncryptedKey.

encryptedValue больше не применяется17. Это поле было отменено вместе со структурой EncryptedValue.

envelopedData содержит зашифрованное значение секретного ключа. Использующие эту структуру протоколы CPR должны определять элемент(ы), для которого данные шифруются (EE, агенты депонирования, УЦ), и способ определения ключа или набора ключей. Подробное описание структуры EnvelopedData приведено в [CMS]. Зашифрованное содержимое должно представлять собой id-ct-encKeyWithID. Идентификатор может быть опущен, если эта структура не используется также для доказательства владения.

6.5. Элемент OldCertID

При наличии элемента OldCertID он указывает сертификат, обновляемый текущим запросом. Идентификатор OID и синтаксис приведены ниже.

   id-regCtrl-oldCertID           OBJECT IDENTIFIER ::= { id-regCtrl 5 }

   CertId ::= SEQUENCE {
         issuer           GeneralName,
         serialNumber     INTEGER
     }

6.6. Элемент protocolEncrKey

При наличии элемента protocolEncrKey он указывает ключ, который CA использует для шифрования откликов на сообщения CertReqMessage. В качестве OID для этого элемента используется id-regCtrl-protocolEncrKey. В качестве структуры параметра для этого поля применяется SubjectPublicKeyInfo (определена в [PROFILE]).

   id-regCtrl-protocolEncrKey     OBJECT IDENTIFIER ::= { id-regCtrl 6 }

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

7. Элементы RegInfo

В этом разделе описаны элементы управления, которые помещаются в поле regInfo структуры CertReqMsg.

7.1. utf8Pairs

Этот элемент управления служит для передачи текстовой информации из Subject агентству RA или CA, выпускающему сертификат. Для этой структуры используется OID id-regInfo-utf8Paris и тип UTF8String.

      id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }

Имя завершается знаком вопроса (?), а значение символом процента (%). Пары «имя-значение» могут повторяться. Таким образом, синтаксис имеет вид

      Name?Value%[Name?Value%]*

Механизм %xx, описанный в разделе 2 STD 66 [RFC3986]18 позволяет представлять символы ? (%3f) и % (%25) при их использовании не в качестве разделителей. Недопустимо использовать имена, начинающиеся с цифры.

Этот элемент может неоднократно включаться в структуру regInfo. При возникновении информационных конфликтов они должны устраняться в соответствии с локальной политикой RA/CA.

В Приложении A приведен список общепринятых имен и форматы данных, соответствующие наиболее часто встречающимся в сертификатах и каталогах полям.

7.2. certReq

Этот элемент управления предназначен для решения проблемы, возникающей в случаях, когда RA требуется изменить шаблон сертификата, предложенный Subject, но этот шаблон используется в Subject при расчете POP. В таких случаях RA может поместить новый шаблон сертификата в regInfo.

Этот элемент имеет OID id-regInfo-certReq и структуру CertRequest. В regInfo может помещаться только один экземпляр данного атрибута. При наличии этого элемента управления в структуре regInfo шаблон сертификата из запроса игнорируется. Агентство RA должно скопировать все данные из основного шаблона в этот атрибут.

      id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }

8. Идентификаторы объектов

OID id-pkix имеет значение

   id-pkix  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
   dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

   -- arc для протоколов Internet X.509 PKI и их компонент
   id-pkip  OBJECT IDENTIFIER :: { id-pkix pkip(5) }

   -- arc для элементов управления Registration в CRMF
   id-regCtrl  OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }

   -- arc для Registration Info в CRMF
   id-regInfo       OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }

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

Протоколы регистрации по своей природе включают большой объем персональных (приватных) данных. Это могут быть ключи, идентификационные номера, номера кредитных карт и т. п. Безопасность любого протокола CRP основана на механизмах защиты протокола и/или процессов, используемый при коммуникациях между CA, RA и EE. Все протоколы должны обеспечивать маскировку (например, с помощью шифрования или отдельной (off-line) обработки) всей «деликатной» пользовательской информации.

Многие протоколы поддерживают проверку первоначального отождествления между CA/RA и EE с помощью маркеров (token). Обычно такой маркер доставляется с использованием отдельных каналов и средств (out-of-band) типа государственной почтовой системы. Защита каналов доставки в этом случае должна соразмеряться с риском перехвата маркера посторонними лицами.

Реализации должны поддерживать значения POP в процессе регистрации сертификатов. Нужен хороший алгоритм POP для доказательства того, что 1) ключ связан с конкретным пользователем и 2) пользователь применяет ключ, о котором идет речь. Отказ от реализации POP позволяет создавать сертификаты без корректной привязки между открытым ключом и именем. Это делает возможной подмену владельца ключа и перехват шифрованных сообщений.

Реализации должны применять генератор случайных чисел с высоким уровнем энтропии при создании секретных ключей. Реализации должны генерировать случайные ключи шифрования содержимого, ключи аутентификации сообщений, векторы инициализации (IV), «затравки» (salt) и заполнение. Применение низкокачественных генераторов псевдослучайных чисел (PRNG19) для создания криптографических ключей может привести к недостаточной защите или ее отсутствию. Для атакующего может оказаться проще воспроизвести среду PRNG, использованную для создания ключей, и провести поиск среди сравнительно небольшого числа вариантов, нежели пытаться подобрать нужное значение из всего пространства ключей. Создание качественных случайных чисел является трудной задачей. В RFC 4086 [RANDOM] приведены важные рекомендации по этим вопросам, а Приложение 3 в FIPS Pub 186 [DSS] описывает один из качественных методов PRNG.

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

Одной из особенностью синтаксиса запросов сертификата является то, что генерация ключей происходит удаленно по отношению к месту создания запроса сертификата. Это свойство никогда не следует применять для запросов генерации ключей подписи. Если ключи подписи создаются для пользователя, вступает в силу элемент отказа (repudiation). Пользователь может заявить, что объект был подписан создавшей ключ стороной или любой другой стороной, которая могла видеть ключ в процессе его передачи от места создания до EE20. Следует принимать меры по защите ключей шифрования удаленным генератором ключей для предотвращения возможности перехвата ключа посторонними. Это означает, что применяемые алгоритмы шифрования должны быть защищены, и должен применяться ключ шифрования содержимого или других ключей для маскировки секретного ключа в процессе его возврата пользователю. Протоколы CRP никогда не должны предполагать, что ключ подписи, созданный пользователем, может применяться для расшифровки пакета, в котором передается секретный ключ шифрования.

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

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

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

[PKCS1] Jonsson, J. and B. Kaliski, «Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1», RFC 3447, February 2003.

[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[PKCS11] RSA Laboratories, The Public-Key Cryptography Standards — «PKCS #11 v2.11: Cryptographic Token Interface Standard», RSA Security Inc., June 2001.

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

[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 3280, April 2002.

[PKIXALG] Bassham, L., Polk, W., and R. Housley, «Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 3279, April 2002.

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

[RFC2875] Prafullchandra, H. and J. Schaad, «Diffie-Hellman Proof-of-Possession Algorithms», RFC 2875, July 2000.

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

[DSS] National Institute of Standards and Technology, FIPS Pub 186: Digital Signature Standard, May 1994.

[PKCS8] RSA Laboratories, «PKCS #8: Private-Key Information Syntax Standard», PKCS #8 v1.2, November 1993.

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

[RFC2202] Cheng, P. and R. Glenn, «Test Cases for HMAC-MD5 and HMAC-SHA-1», RFC 2202, September 1997.

[RFC3986]21 T. Berners-Lee, R. Fielding, L. Masinter «Uniform Resource Identifier (URI): Generic Syntax», RFC 3986, January 2005.

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

Рабочая группа благодарит Michael Myers, Carlisle Adams, Dave Solo и David Kemp, создавших исходный вариант этого документа.

Рабочая группа выражает свою признательность участникам Barbara Fox, Warwick Ford, Russ Housley и John Pawling, чьи рецензии и комментарии сделали эту спецификацию значительно яснее и полезней. Спасибо также участникам почтовой конференции ca-talk за их полезные предложения в части тестирования интероперабельности.

Текст Приложения C (Зачем использовать POP) был взят из почтового сообщения Al Arsenault и изначально являлся частью документа PKIX Roadmap.

Приложение A. Использование RegInfo для пар Name-Value

Поле value строки id-regInfo-utf8Pairs (с полем tag = 12 и подходящим полем length) будет содержать последовательность пар «имя-значение» в формате UTF-8.

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

A.1. Определенные имена

В таблице приведен рекомендуемый набор именованных элементов. Значения в колонке «Имя» содержат именно те строки, которые будут появляться в regInfo.

Имя

Описание

version

Версия данной вариации, которую использует regInfo.

corp_company

Компания подписчика.

org_unit

Подразделение организации.

mail_firstName

Компонента персонального имени.

mail_middleName

Компонента персонального имени.

mail_lastName

Компонента персонального имени.

mail_email

Адрес электронной почты подписчика.

jobTitle

Должность подписчика.

employeeID

Числовой или текстовый идентификатор сотрудника.

mailStop

issuerName

Название УЦ.

subjectName

Название субъекта.

validity

Срок действия.

Например,

      version?1%corp_company?Example, Inc.%org_unit?Engineering%
      mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader%
      mail_email?john@example.com%

A.2. Представление IssuerName, SubjectName и Validity

При включении в id-regInfo-utf8Pairs в качестве именованных элементов для кодирования значений issuerName, subjectName и validity нужно использовать описанный ниже синтаксис. Символы [] указывают необязательные поля, ::= и | применяются в обычном для BNF смысле, а все остальные символы (за исключением незначимых пробелов) вне имен являются завершающими (terminal). Регистр символов принимается во внимание.

      issuerName  ::= <names>
      subjectName ::= <names>
      <names>     ::= <name> | <names>:<name>

      <validity>  ::= validity ? [<notbefore>]-[<notafter>]

      <notbefore> ::= <time>
      <notafter>  ::= <time>

<time> указывает время UTC в формате YYYYMMDD[HH[MM[SS]]]. Компоненты HH, MM и SS по умолчанию имеют значения 00 и опускаются, если за ними нет отличных от 00 символов.

Примером представления validity может служить

      validity?-19991231%

где начало действия (notBefore) не задано, а заканчивается срок действия 31 декабря 1999 года (notAfter).

Каждое имя содержит один символ идентификатора формы, за которым следует значение имени из одного или множества символов UTF-8. Внутри значения имени для устранения неоднозначностей при наличии символов форматирования внешнего уровня нужно использовать escape-последовательности вида %xx, где xx указывает шестнадцатеричный код символа. Сам символ процента представляется последовательностью %%.

      <name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>

Форматы имен описаны ниже.

Форма имени каталога X.500 (идентификатор X)

      <xname> ::= <rdns>
      <rdns>  ::= <rdn> | <rdns> , <rdn>
      <rdn>   ::= <avas>
      <avas>  ::= <ava> | <avas> + <ava>
      <ava>   ::= <attyp> = <avalue>
      <attyp> ::= OID.<oid> | <stdat>

Стандартный тип атрибута <stdat> представляет собой символьный идентификатор типа атрибута из числа приведенных ниже.

C (страна)

L (населенный пункт)

ST (штат или провинция)

O (организация)

OU (подразделение организации)

CN (имя)

STREET (адрес)

E (адрес электронной почты).

Компонента имени <avalue> представляет собой строку UTF-8 размером от 1 до 64 символов с ограничением использования в подмножестве IA5 кодировки UTF-только символов ASN.1 PrintableString.

Другая форма имени (идентификатор O)

      <oname> ::= <oid> , <utf8string>

Адрес электронной почты (rfc822name) (идентификатор E)

      <ename> ::= <ia5string>

Имя DNS (идентификатор D)

      <dname> ::= <ia5string>

Идентификатор URI (идентификатор U)

      <uname> ::= <ia5string>

Адрес IP (идентификатор I)

      <iname> ::= <oid>

Например,

      issuerName?XOU=Our CA,O=Example,C=US% subjectName?XCN=John Smith,
      O=Example, C=US, E=john@example.com%

Приложение B. Структуры и идентификаторы ASN.1

PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)}

DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
  -- Схема проверки подлинности каталога (X.509)
     Version, AlgorithmIdentifier, Name, Time,
     SubjectPublicKeyInfo, Extensions, UniqueIdentifier, Attribute
        FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
            internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
            id-pkix1-explicit(18)} -- найдено в [PROFILE]

  -- Расширения сертификата (X.509)
     GeneralName
        FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
               internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
               id-pkix1-implicit(19)}  -- найдено в [PROFILE]

  -- Синтаксис криптографических сообщений
     EnvelopedData
        FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
             modules(0) cms-2004(24) };  -- найдено в [CMS]

-- Комментарий для приведенного ниже определения можно удалить при использовании
-- компиляторов ASN.1, не понимающих UTF8String.

-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
       -- содержимое этого типа соответствует RFC 362922.

id-pkix  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }

-- arc для протоколов Internet X.509 PKI и их компонент

id-pkip  OBJECT IDENTIFIER ::= { id-pkix 5 }

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

id-ct   OBJECT IDENTIFIER ::= { id-smime  1 }  -- типы содержимого

-- Основные определения для этого модуля

CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
 certReq   CertRequest,
 popo       ProofOfPossession  OPTIONAL,
 -- содержимое зависит от типа ключа
 regInfo   SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }

CertRequest ::= SEQUENCE {
 certReqId     INTEGER,            -- ID для сопоставления запроса и отклика
 certTemplate  CertTemplate,       -- выбранные поля для выпускаемого сертификата
 controls      Controls OPTIONAL } -- атрибуты, влияющие на эмиссию сертификата

CertTemplate ::= SEQUENCE {
 version      [0] Version               OPTIONAL,
 serialNumber [1] INTEGER               OPTIONAL,
 signingAlg   [2] AlgorithmIdentifier   OPTIONAL,
 issuer       [3] Name                  OPTIONAL,
 validity     [4] OptionalValidity      OPTIONAL,
 subject      [5] Name                  OPTIONAL,
 publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
 issuerUID    [7] UniqueIdentifier      OPTIONAL,
 subjectUID   [8] UniqueIdentifier      OPTIONAL,
 extensions   [9] Extensions            OPTIONAL }

OptionalValidity ::= SEQUENCE {
 notBefore  [0] Time OPTIONAL,
 notAfter   [1] Time OPTIONAL } -- ДОЛЖЕН присутствовать хотя бы один

Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
 type         OBJECT IDENTIFIER,
 value        ANY DEFINED BY type }
ProofOfPossession ::= CHOICE {
 raVerified        [0] NULL,
 -- используется в тех случаях, когда агентство RA уже убедилось в том, что
 -- запрашивающий владеет секретным ключом
 signature         [1] POPOSigningKey,
 keyEncipherment   [2] POPOPrivKey,
 keyAgreement      [3] POPOPrivKey }

POPOSigningKey ::= SEQUENCE {
 poposkInput           [0] POPOSigningKeyInput OPTIONAL,
 algorithmIdentifier   AlgorithmIdentifier,
 signature             BIT STRING }

 -- Подпись (использует algorithmIdentifier) является DER-представлением 
 -- poposkInput. Отметим, что при наличии в CertReqMsg certReq CertTemplate
 -- значений subject и publicKey поле poposkInput ДОЛЖНО опускаться, а 
 -- подпись ДОЛЖНА рассчитываться для DER-представления CertReqMsg certReq. 
 -- Если CertReqMsg certReq CertTemplate не включает открытого ключа и
 -- подписи (т. е., включет только одно или не содержит обоих), ДОЛЖНО
 -- быть представлено и подписано поле poposkInput.

POPOSigningKeyInput ::= SEQUENCE {
 authInfo            CHOICE {
     sender              [0] GeneralName,
     -- Используется только в тех случаях, когда для отправителя имеется
     -- аутентифицированное отождествление (например, DN из выпущенного
     -- ранее и действительного сейчас сертификата)
     publicKeyMAC        PKMACValue },
     -- Используется в тех случаях, когда для отправителя нет аутентифицированного
     -- GeneralName; publicKeyMAC содержит основанный на пароле код MAC для
     -- DER-представления publicKey
 publicKey           SubjectPublicKeyInfo }  -- из CertTemplate

PKMACValue ::= SEQUENCE {
algId  AlgorithmIdentifier,
-- Значение алгоритма должно быть PasswordBasedMac {1 2 840 113533 7 66 13}
-- Значение параметра - PBMParameter
value  BIT STRING }

PBMParameter ::= SEQUENCE {
   salt                OCTET STRING,
   owf                 AlgorithmIdentifier,
   -- AlgId для необратимой функции (рекомендуется SHA-1)
   iterationCount      INTEGER,
   -- Число итераций применения OWF
   mac                 AlgorithmIdentifier
   -- MAC AlgId (например, DES-MAC, Triple-DES-MAC [PKCS11] или
}  -- HMAC [HMAC, RFC2202])

POPOPrivKey ::= CHOICE {
 thisMessage       [0] BIT STRING,         -- Отменено
 -- Владение подтверждено в этом сообщении (которое содержит 
 -- секретный ключ, зашифрованный для )
 subsequentMessage [1] SubsequentMessage,
 -- Владение будет подтверждено в следующем сообщении
 dhMAC             [2] BIT STRING,         -- Отменено
 agreeMAC          [3] PKMACValue,
 encryptedKey      [4] EnvelopedData }

 -- Для keyAgreement (и только для него) владение подтверждено в этом сообщении
 -- (оно содержит MAC (для DER-представления параметра certReq в
 -- CertReqMsg, который ДОЛЖЕН включать subject и publicKey)
 -- на основе ключа, полученного из секретного ключа DH конечного объекта 
 -- и открытого ключа DH агентства CA);

SubsequentMessage ::= INTEGER {
 encrCert (0),
 -- Запрос, который приводит к шифрованию сертификата для конечного объекта
 -- (POP будет представлено в подтверждающем сообщении)
 challengeResp (1) }
 -- Запрашивает у CA обмен «запрос-отклик» (challenge-response) с конечным объектом
 -- для подтверждения обладания секретным ключом.

-- Выделение идентификаторов объектов --

-- Регистрационные элементы в CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }

id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
-- с синтаксисом
RegToken ::= UTF8String

id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
-- с синтаксисом
Authenticator ::= UTF8String

id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
-- с синтаксисом
PKIPublicationInfo ::= SEQUENCE {
action     INTEGER {
             dontPublish (0),
             pleasePublish (1) },
pubInfos  SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
  -- НЕДОПУСТИМО наличие pubInfos для действия dontPublish
  -- (если указано действие pleasePublish и pubInfos отсутствует,
  -- предполагается dontCare)

SinglePubInfo ::= SEQUENCE {
 pubMethod    INTEGER {
     dontCare    (0),
     x500        (1),
     web         (2),
     ldap        (3) },
 pubLocation  GeneralName OPTIONAL }

id-regCtrl-pkiArchiveOptions     OBJECT IDENTIFIER ::= { id-regCtrl 4 }
-- с синтаксисом
PKIArchiveOptions ::= CHOICE {
 encryptedPrivKey     [0] EncryptedKey,
 -- актуальное значение секретного ключа
 keyGenParameters     [1] KeyGenParameters,
 -- параметры, позволяющие заново создать секретный ключ
 archiveRemGenPrivKey [2] BOOLEAN }
 -- Устанавливается TRUE, если отправитель хочет, чтобы получатель архивировал
 -- секретный ключ пары, которую получатель создал в ответ на этот запрос;
 -- FALSE указывает нежелательность архивирования.

EncryptedKey ::= CHOICE {
 encryptedValue        EncryptedValue,   -- Deprecated
 envelopedData     [0] EnvelopedData }
 -- Зашифрованный секретный ключ ДОЛЖЕН помещаться в строку октетов 
 -- envelopedData encryptedContentInfo encryptedContent.

EncryptedValue ::= SEQUENCE {
 intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
 -- Алгоритм, для которого значение будет использоваться
 symmAlg       [1] AlgorithmIdentifier  OPTIONAL,
 -- Симметричный алгоритм, используемый для шифрования значения
 encSymmKey    [2] BIT STRING           OPTIONAL,
 -- (Зашифрованный) симметричный ключ, который будет использоваться для шифрования значения
 keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
 -- Алгоритм, используемый для шифрования симметричного ключа
 valueHint     [4] OCTET STRING         OPTIONAL,
 -- Краткое описание или идентификатор содержимого encValue
 -- (может быть осмысленным только для передающей стороны и применяется лишь 
 -- в тех случаях, когда EncryptedValue может быть в будущем перепроверено 
 -- передающей стороной)
 encValue       BIT STRING }
 -- Зашифрованное значение
-- При использовании EncryptedValue для передачи секретного ключа (в отличие от 
-- сертификата) реализации ДОЛЖНЫ поддерживать поле encValue, содержащее зашифрованное
-- значение PrivateKeyInfo, как указано в параграфе 12.11 [PKCS11]. Если encValue
-- содержит какой-либо иной формат или кодирование секретного ключа, первый октет
-- valueHint МОЖЕТ служить для указания этого формата илипредставления (отметим, 
-- что возможные значения этого октета еще не определены). Во всех случаях поле 
-- intendedAlg ДОЛЖНО использоваться для указания хотя бы OID предусмотренного алгоритма
-- секретного ключа, если такая информация не известна заранее обеим сторонам.

KeyGenParameters ::= OCTET STRING

id-regCtrl-oldCertID          OBJECT IDENTIFIER ::= { id-regCtrl 5 }
-- с синтаксисом
OldCertId ::= CertId
CertId ::= SEQUENCE {
 issuer           GeneralName,
 serialNumber     INTEGER }

id-regCtrl-protocolEncrKey    OBJECT IDENTIFIER ::= { id-regCtrl 6 }
-- с синтаксисом
ProtocolEncrKey ::= SubjectPublicKeyInfo

-- Регистрационная информация в CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }

id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
-- с синтаксисом
UTF8Pairs ::= UTF8String

id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }
-- с синтаксисом
CertReq ::= CertRequest

-- id-ct-encKeyWithID является новым типом содержимого для объектов CMS
-- и содержит секретный ключ вместе с идентификатором для агентов депонирования
-- ключей, обеспечивающих возможность проверки при запросах на восстановление.

id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}

EncKeyWithID ::= SEQUENCE {
  privateKey           PrivateKeyInfo,
  identifier CHOICE {
    string             UTF8String,
    generalName        GeneralName
  } OPTIONAL
}

PrivateKeyInfo ::= SEQUENCE {
   version                   INTEGER,
   privateKeyAlgorithm       AlgorithmIdentifier,
   privateKey                OCTET STRING,
   attributes                [0] IMPLICIT Attributes OPTIONAL
}

Attributes ::= SET OF Attribute

END

Приложение C. Зачем использовать POP

Процедура подтверждения владения (POP) служит для предоставления удостоверяющему центру (CA) убедительных доказательств того, что сторона, запросившая сертификат для открытого ключа Y, имеет доступ к соответствующему секретному ключу X.

Важность процедуры POP обусловлена тем, что она обеспечивает надлежащий уровень уверенности в корректности работы PKI в целом. На самом низком уровне POP противостоит «самонавязанному отказу в обслуживании» (self-inflicted denial of service), т. е., запрашивающий сам получает сертификат, который не может использоваться для шифрования/расшифровки информации. Однако, как показано в двух примерах ниже, POP препятствует также менее прямым, но более серьезным угрозам.

POP для ключей подписи. Важно обеспечить POP для ключей, используемых с целью подписывания документов, чтобы обеспечить невозможность отказа от выполненной транзакции. Предположим, например, что Алиса правомерно владеет секретным ключом X, которому соответствует открытый ключ Y. Алиса имеет сертификат от Чарли — УЦ, хранящего Y. Алиса использует ключ X для подписи транзакции T. При отсутствии POP некто Мэл также может получить от Чарли сертификат, содержащий открытый ключ Y. В этом случае возможны две угрозы — Мэл может заявить, что она на самом деле подписала транзакцию T, а Алиса может отказаться от своей подписи T, заявив, что это сделала Мэл. Поскольку нет возможности убедительно доказать или опровергнуть обладание Мэл ключом X, ни одно из указанных выше заявлений не может быть опровергнуто и, следовательно, доверие к PKI теряется (естественно, что при реальном обладании Мэл секретным ключом Алисы Х, никакой механизм POP не поможет, но это уже другая проблема).

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

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

POP для ключей управления ключами. Аналогично, POP для ключей управления ключами (т. е., согласования или обмена ключами) может помочь в предотвращении подрыва доверия к PKI. Предположим, что Эл является новым преподавателем в местном компьютерном университете и создал предварительный вариант экзамена по курсу «Введение в сети», который он читает. Эл хочет передать копию документа декану факультета Дороти для одобрения. Документ зашифрован, поскольку некоторые студенты имеют доступ к компьютерной системе. Однако быстрый поиск в репозитории сертификатов (например, поиск всех записей, где поле subjectPublicKey содержит значение Дороти) показывает, что некоторые студенты пользуются таким же открытом ключом для управления ключами, какой применяет Дороти. В этом случае, если УЦ не использует процедуру POP, Эл не будет иметь возможности узнать, кто из студентов просто создал эти сертификаты, не зная секретного ключа Дороти (это позволяет безопасно передать документ), а кто действительно завладел им (это ставит передачу документа под угрозу расшифровки). Таким образом, услуги PKI, обеспечивающие пользователям уверенность в том, что они общаются именно с тем человеком, который представился, полностью утрачивают доверие. Если УЦ поддерживает процедуру POP, ни у кого из студентов такого сертификата быть не может и это позволяет Элу передать документ Дороти, будучи уверенным в его недоступности студентам.

Адрес автора

Jim Schaad

Soaring Hawk Consulting

PO Box 675

Gold Bar, WA 98251

EMail: jimsch@exmsft.com

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

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

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Certificate Request Message Format — формат сообщения запроса сертификата.

2Certification Authority — удостоверяющий центр.

3Registration Authority — регистрационное агентство, регистратор.

4Certificate Request Message — сообщение запроса сертификата.

5Certificate Request Protocol — протокол запроса сертификата.

6End Entity — конечный объект.

7Proof-of-possession (POP) — доказательство обладания.

8В оригинале нумерация после п. 7 ошибочна. См. https://www.rfc-editor.org/errata_search.php?eid=2595. Прим. перев.

9В оригинале ошибочно сказано «шаблона сертификата». См. https://www.rfc-editor.org/errata_search.php?eid=4797. Прим. перев.

10В оригинале допущена ошибка. См. https://www.rfc-editor.org/errata_search.php?eid=166. Прим. перев.

11В исходном документе здесь допущена ошибка. См. https://www.rfc-editor.org/errata_search.php?eid=2340. Прим. перев.

12В оригинале опечатка — ). См. https://www.rfc-editor.org/errata_search.php?eid=2341. Прим. перев.

13В оригинале опечатка — PEMParameter. См. https://www.rfc-editor.org/errata_search.php?eid=2342. Прим. перев.

14В оригинале ошибочно сказано 7.2. См. https://www.rfc-editor.org/errata_search.php?eid=2343. Прим. перев.

15В оригинале опечатка. См. https://www.rfc-editor.org/errata_search.php?eid=2344. Прим. перев.

16В оригинале опечатка — pubInfos. См. https://www.rfc-editor.org/errata_search.php?eid=2345. Прим. перев.

17В оригинале опечатка. См. https://www.rfc-editor.org/errata_search.php?eid=2346. Прим. перев.

18В оригинале ошибочно указан RFC 1738. См. https://www.rfc-editor.org/errata_search.php?eid=2347. Прим. перев.

19Pseudo-random number generator.

20В оригинале опечатка. См. https://www.rfc-editor.org/errata_search.php?eid=2348. Прим. перев.

21В оригинале ошибочно указан RFC 1738. См. https://www.rfc-editor.org/errata_search.php?eid=2349. Прим. перев.

22В оригинале ошибочно сказано RFC 2279. См. https://www.rfc-editor.org/errata_search.php?eid=2339. Прим. перев.




RFC 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)

Network Working Group                                       C. Adams
Request for Comments: 4210                      University of Ottawa
Obsoletes: 2510                                           S. Farrell
Category: Standards Track                     Trinity College Dublin
                                                            T. Kause
                                                                 SSH
                                                          T. Mononen
                                                             SafeNet
                                                      September 2005

Протокол управления сертификатами в инфраструктуре открытых ключей Internet X.509

Internet X.509 Public Key Infrastructure

Certificate Management Protocol (CMP)

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

В этом документе описан протокол управления сертификатами (CMP1) в инфраструктуре открытых ключей (PKI2) Internet X.509. Определены протокольные сообщения для создания сертификатов X.509v3 и управления ими. Протокол CMP обеспечивает интерактивное взаимодействие между компонентами PKI, включая обмен данными между агентами сертификации (CA3) и клиентскими системами.

Оглавление

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

1. Введение

В этом документе описан протокол управления сертификатами (CMP4) в инфраструктуре открытых ключей (PKI5) Internet X.509. Определены протокольные сообщения для создания сертификатов X.509v3 и управления ими. Термин «сертификат» в данном документе обозначает сертификат X.509v3 в соответствии с определением [X509].

Данная спецификация отменяет документ RFC 2510 и имеет ряд отличий от RFC 2510:

  • Раздел описания профиля управления PKI разделен на два приложения — обязательный профиль и дополнительный профиль. Некоторые из обязательных прежде функций перенесены в опциональный профиль.
  • Существенно изменен механизм подтверждения сообщений.
  • Введен новый механизм опроса, запрещающий старый метод опроса на транспортном уровне CMP.
  • Транспортный протокол CMP вынесен в отдельный документ [CMPtrans] и соответствующий раздел удален из данной спецификации.
  • Введен новый метод явного подтверждения для снижения числа сообщений в одной транзакции..
  • В новой спецификации в протокол внесены незначительные усовершенствования, а также прояснены некоторые детали описания.

2. Уровни требований

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

3. Обзор управления PKI

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

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

3.1. Модель управления PKI

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

3.1.1. Определения элементов PKI

Элементы, вовлеченные в управление PKI, включают конечные элементы (т. е., элементы, для которых выпускаются сертификаты) и агенты сертификации (элементы, выдающие сертификаты). В управлении PKI может также участвовать агент регистрации.

3.1.1.1. Субъекты и конечные элементы

Термин «субъект» в этом документе обозначает элементы, для которых выдаются (вводятся) сертификаты. Обычно имя этого элемента указывается в поле сертификата subject или subjectAltName. Когда нужно различать инструменты и/или программы, используемые субъектом (например, локальный модуль управления сертификатами), будем называть их «оборудованием субъекта». В общем случае вместо термина «субъект» предпочтительно использовать термин «конечный элемент» (EE6), во избежание путаницы с именем поля. Важно отметить, что в данном случае к конечному элементу относится не только человек, использующий программные приложения, но и сами такие приложения (например, средства защиты IP). Это оказывает влияние на протокол, используемый для работы управления PKI, — например, прикладные программы обычно знают более точно, чем пользователь-человек, какие расширения сертификатов нужны. Элементы управления PKI являются также конечными элементами в том смысле, что они иногда указываются в полях subject или subjectAltName сертификатов или кросс-сертификатов. Там, где это возможно, термин «конечный элемент» будет относиться к элементам, не являющимся элементами управления PKI.

Все конечные элементы требуют локальной защиты доступа к той или иной информации — по крайней мере, имя и секретный ключ элемента, имя CA, которому данный элемент доверяет напрямую, а также открытый ключ этого CA (или оттиск открытого ключа в тех случаях, когда доступна само-сертифицированная версия). Разработчики могут использовать защищенное локальное хранилище, обеспечивающее хранение дополнительных данных (например, сертификат владельца конечного элемента или специфические данные приложения). Форма защищенного хранилища может меняться от обычных файлов до защищенных от копирования маркеров (брелоков). Информацию, находящуюся в таких защищенных локальных хранилищах, будем называть персональной средой защиты (PSE7) конечного элемента.

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

3.1.1.2. Агент сертификации

Агент сертификации (CA) с точки зрения конечного элемента может быть (или не быть) «третьей стороной». Достаточно часто на практике CA относится к той же организации, которой принадлежат поддерживаемые агентом конечные элементы.

Термин «CA» будет использоваться для обозначения элементов, указываемых в поле эмитента (issuer) сертификата. Говоря о программах или аппаратных компонентах, используемых CA, будем применять термин «оборудование CA».

Оборудование CA зачастую будет включать «подключаемые» (off-line) и «постоянно включенные» (on-line) компоненты. Секретный ключ CA может размещаться только на подключаемых компонентах. Этот вопрос относится к компетенции разработчиков (хотя он связан также в политикой безопасности).

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

«Второстепенными9» (подчиненными) агентами CA будем называть агенты, которые не являются корневыми CA для рассматриваемого конечного элемента. Зачастую второстепенные CA не являются корневыми агентами ни для какого элемента, но это не обязательно.

3.1.1.3. Агент регистрации

В дополнение к конечным элементам и агентам CA во вногих средах могут использоваться агенты регистрации (RA10), отличающиеся от CA. Выполняемые такими агентами функции зачастую существенно различаются, но могут включать персональную идентификацию, распространение маркеров (token), отчеты об отзыве (сертификатов), выделение имен, генерацию ключей, архивирование ключевых пар и т. п..

В этом документе RA считаются опциональными компонентами. При отсутствии агента регистрации предполагается, что все функции RA выполняет CA, поэтому протоколы управления PKI совпадают с точки зрения конечного элемента.

Используемые агентами регистрации средства будем называть «оборудованием RA».

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

При некоторых условиях конечные элементы будут напрямую взаимодействовать с CA даже при наличии RA. Например, для начальной регистрации и/или сертификации субъект может использовать RA, но напрямую взаимодействовать с CA для обновления своего сертификата.

3.1.2. Требования к управлению PKI

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

  1. Управление PKI должно соответствовать стандартам ISO/IEC 9594-8/ITU-T X.509.
  2. Должна обеспечиваться возможность регулярного обновления любой пары ключей без воздействия на другие ключевые пары.
  3. Защита конфиденциальности в протоколе управления PKI должна быть сведена к минимуму для того, чтобы упростить использование в средах, где строгая защита конфиденциальности может вызывать юридические проблемы.
  4. Протоколы управления PKI должны позволять использование различных стандартизованных алгоритмов шифрования (в частности, RSA, DSA, MD5, SHA-1). Это значит, что любой CA, RA или конечный элемент в принципе может выбирать алгоритмы для своих ключевых пар.
  5. Протоколам управления PKI недопустимо препятствовать генерации ключевых пар конечными элементами, вовлеченными в процесс, а также агентами RA или CA. Генерация ключей может выполняться в разных местах, но для целей управления PKI можно считать, что генерация выполняется там, где ключ впервые появляется на конечном элементе, RA или CA.
  6. Протоколы управления PKI должны поддерживать публикацию сертификатов вовлеченными в процесс конечными элементами, а также агентами RA или CA. В разных реализациях и средах могут выбираться любые из перечисленных вариантов.
  7. Протоколы управления PKI должны поддерживать создание списков отозванных сертификатов (CRL11), позволяя конечным элементам делать запросы на отзыв сертификатов. Это должно осуществляться таким способом, который не позволял бы простыми средствами организовать атаку на отказ служб (DoS12).
  8. Протоколы управления PKI должны обеспечивать возможность работы на основе различных «транспортных» механизмов, включая, в частности, электронную почту http, TCP/IP и ftp.
  9. Окончательное решение о создании сертификата остается за агентом CA. Ни RA, ни конечный элемент не могут предполагать, что выпущенный агентом CA сертификат будет в точности содержать запрошенные значения — CA может менять значения полей сертификата, добавлять, удалять или менять расширения в соответствии с правилами работы. Иными словами, все элементы PKI (конечные элементы, RA и CA) должны быть способны обрабатывать отклики на запросы сертификатов, в которых выдаваемые сертификаты отличаются от запрашиваемых (например, агент CA может сократить срок действия сертификата). Отметим, что правила могут запрещать агенту CA публиковать или иным способом распространять сертификат, пока запросившая сторона не рассмотрит и не примет созданный сертификат (обычно с помощью сообщения certConf).
  10. Должен поддерживаться аккуратный, планируемый переход от одной пары ключей нескомпрометированного13 агента CA к следующей паре (обновление ключа CA). Конечный элемент, среда PSE которого содержит новый открытый ключ CA (в результате обновления ключа CA), должен также быть способен проверить верифицируемость сертификатов с помощью старого открытого ключа. Конечные элементы, которые доверяют старой паре ключей CA непосредственно, должны быть способны также проверить сертификаты, подписанные с использованием нового секретного ключа CA (это требуется в ситуациях, когда старый открытый ключ CA являлся «аппаратной» частью клиптографического оборудования элемента).
  11. В некоторых реализациях и средах функции агента регистрации RA могут выполняться непосредственно агентом CA. Протоколы должны быть устроены так, чтобы конечные элементы взаимодействовали с агентами RA и CA в таких ситуациях по одному протоколу. Естественно, что конечный элемент для защиты при обмене данными должен использовать в таких случаях корректный открытый ключ RA для агента CA.
  12. Когда конечный элемент запрашивает сертификат, содержащий заданное значение открытого ключа, этот конечный элемент должен быть готов продемонстрировать владение соответствующим закрытым ключом. Это можно реализовать разными способами в зависимости от типа запроса сертификата. В параграфе 4.3 описаны методы обмена данными по основному каналу (in-band), определенные для сообщений PKIX-CMP14.

3.1.3. Операции управления PKI

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

+---+  публикация сертификата  +------------+      j
|   |  <---------------------  |конеч. элем.| <-------
| Р |             g            +------------+     загрузка
| е |                            | ^        «по отдельному каналу»
| п |                            | |      начальная
| о |                          a | | b    регистрация/
| з |                            | |      сертификация
| и |                            | |      восстанов. ключевой пары
| т |                            | |      обновление ключевой пары
| о |                            | |      обновление сертификата
| и |  «Пользователи» PKI        V |      запрос на отзыв
| й | -------------------+-+-----+-+------+-+-------------------
|   |  Элементы          | ^              | ^
| с |  управл. PKI     a | | b          a | | b
| е |                    V |              | |
| р |             g   +------+    d       | |
| т |   <------------ |  RA  | <-----+    | |
| и |     публикация  |      | ----+ |    | |
| ф |     сертификата +------+   c | |    | |
| . |                              | |    | |
| / |                              V |    V |
| C |          g                 +------------+   i
| L |   <------------------------|     CA     |------->
| R |          h                 +------------+  публикация
|   |    публикация сертификата       | ^   «по отдельному каналу»
|   |    публикация CRL publish       | |
+---+                                 | |    кросс-сертификация
                                    e | | f  обновление
                                      | |    кросс-сертификации
                                      V |
                                    +------+
                                    | CA-2 |
                                    +------+

Рисунок 1: Элементы PKI

Набор операций верхнего уровня, для которых определены управляющие сообщения, показан ниже.

  1. Организация CA. При организации нового агента CA некоторые этапы (например. Создание начальных CRL, экспорт открытого ключа CA) являются обязательными.
  2. Инициализация конечного элемента включает импорт открытого ключа корневого CA и запрос информации об опциях, поддерживаемых элементом управления PKI.
  3. Сертификация. Различные операции, приводящие к созданию новых сертификатов:
    1. Начальная регистрация/сертификация. Это процесс, в котором конечный элемент впервые представляет себя агенту CA или RA до эмиссии агентом CA сертификата или сертификатов для данного конечного элемента. Результа-том этого процесса (при успешном за-вершении) является эмиссия агентом CA открытого ключа для конечного элемента, возврат сертификата и/или отправка этого сертификата в публичное хранилище (репозиторий). Процесс может (и, как правило, будет) состоять из множества «этапов», которые могут включать инициализацию оборудования конечного элемента. Например, оборудование конечного элемента должно быть безопасно инициализировано с помощью открытого ключа CA, который будет использоваться при проверке путей сертификатов. Кроме того, конечные элементы обычно требуется инициализировать с использованием их собственных ключевых пар.
    2. Обновление ключевой пары. Каждую прау ключей требуется регулярно обновлять (т. е., заменять новой парой ключей) и выпускать новый сертификат.
    3. Обновление сертификата. При завершении срока действия сертификата он может быть «обновлен», если в среде не произошло связанных с этим сертификатом изменений.
    4. Обновление пары ключей CA. Как и для конечных элементов ключевые пары агентов CA требуется регулярно менять. Однако при такой замене требуются иные механизмы.
    5. Запрос кросс-сертификации. Агент CA запрашивает эмиссию кросс-сертификата у другого CA. В данном стандарте «кросс-сертификатом» называется сертификат, в котором CA-субъект и CA-эмитент различаются, а поле SubjectPublicKeyInfo содержит ключ верификации (т. е., сертификат, выданный для пары ключей, используемой CA-субъектом в подписях). В некоторых случаях, когда требуется более тонкое различие, кросс-сертификат называется «междоменным» (участвующие в процессе агенты CA относятся к разным административным доменам) или «внутридоменным» (в остальных случаях).
    6. Обновление кросс-сертификата. Похоже на обновление сертификата, но включает кросс-сертификацию.
    Примечание 1. Приведенное выше определение «кросс-сертификата» соответствует определению «сертификата CA» в стандарте X.509. Не следует путать этот термин с типом атрибута «cACertificate» в стандарте X.500.
    Примечание 2. Во многих средах термин «кросс-сертификат» трактуется, как синоним термина «междоменный кросс-сертификат», если явно не указано иное.
    Примечание 3. Эмиссия кросс-сертификатов может (но не обязана) быть взаимной, когда оба агента CA выпускают кросс-сертификаты один для другого.
  4. Операции обнаружения сертификата/CRL. Некоторые операции управления PKI, приводящие к публикации сертификатов или CRL:
    1. Публикация сертификата. После решения проблем, связанных с сосзданием сертификата, требуются некоторые меры по его публикации. «Меры», определенные в PKIX могут включать сообщения, определенные в параграфах 5.3.13 — 5.3.16, или иные методы (например, LDAP), описанные в [RFC2559] и [RFC2585] (документы «Operational Protocols» в серии спецификаций PKIX).
    2. Публикация CRL. Аналогичная публикации сертификата.
  5. Операции восстановления. Некоторые операции управления PKI, используемые при «потере» конечным элементом своей среды PSE:
    1. Восстановление ключевой пары. Опционально пользовательский ключевой материал (например, секретный ключ пользователя, используемый для расшифровки) могут сохраняться (резервная копия) агентами CA и RA или системой резервного копирования ключей, связанной с CA или RA. Если клиенту требуется восстановить сохраненный в резервной копии ключевой материал (например, в случае забытого пароля или утраченного файла цепочки ключей15), для такого восстановления может потребоваться обмен протокольными сообщениями.
  6. Операции отзыва. Операции управления PKI. приводящие к созданию новых записей CRL и/или новых CRL:
    1. Запрос на отзыв. Уполномоченное лицо может уведомить CA об аномальной ситуации, требующей отзыва сертификата.
  7. Операции PSE. Хотя определение операций PSE (например, перемещение PSE, смена PIN и т. п.) выходит за пределы данной спецификации, мы определяем сообщение PKIMessage (CertRepMessage) которое может стать основой для таких операций.

Отметим, что интерактивные протоколы не являются единственным способом выполнения перечисленных выше операций. Для всех операций возможны автономные (off-line) методы достижения того же результата и данная спецификация не требует использования протоколов on-line. Например, при использовании аппаратных маркеров, многие операции могут быть выполнены в процессе физической доставки маркеров.

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

4. Допущения и ограничения

4.1. Инициализация конечного элемента

Первым шагом конечного элемента при работе с объектами управления PKI является запрос информации о поддерживаемых функциях PKI и защищенное получение копии соответствующего открытого ключа (или ключей) корневого агента CA.

4.2. Начальная регистрация/сертификация

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

Однако можно классифицировать схемы начальной регистрации/сертификации, которые поддерживаются данной спецификацией. Отметим, что слово «начальная» в предыдущем предложении играет важную роль — мы имеем дело с ситуацией, когда рассматриваемый конечный элемент ранее не имел контактов с PKI. Когда конечный элемент уже владеет ключами сертификации, возможно некоторое упрощение/изменение процедуры.

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

Далее приводится классификация схем начальной регистрации/сертификации.

4.2.1. Используемые критерии

4.2.1.1. Инициирование регистрации/сертификации

В терминах создаваемых сообщений PKI можно рассматривать инициирование обмена при начальной регистрации/сертификации, как создание первого сообщения PKI, связанного с этим конечным элементом. Отметим, что в реальности процедура начальной регистрации/сертификации может происходить иначе (например, отдел персонала может обратиться по телефону к оператору RA).

К числу возможных мест относятся конечный элемент, RA или CA.

4.2.1.2. Идентификация источника сообщения от конечного элемента

Интерактивные (on-line) сообщение, создаваемые конечным элементом, которому нужен сертификат, могут быть или не быть идентифицированными. Требование заключается в проверке подлинности источника любых сообщений от конечного элемента к PKI (CA/RA).

В данной спецификации такая проверка осуществляется PKI (CA/RA), вводящим конечный элемент с секретным значением (начальный ключ аутентификации) и эталонным значением (служит для идентификации секретного значения) с использованием неких иных каналов передачи информации (out-of-band). После этого можно использовать начальный ключ аутентификации для защиты соответствующих сообщений PKI.

Таким образом, можно классифицировать схемы начальной регистрации/сертификации по наличию проверки подлинности интерактивных сообщений от конечного элемента к PKI.

Примечание 1. Здесь не рассматривается аутентификация сообщений от PKI к конечному элементу, поскольку такая аутентификация обязательна. В любом случае эта аутентификация может быть обеспечена после получения открытого ключа корневого CA оборудованием конечного элемента или выполнена с использованием ключа начальной аутентификации.

Примечание 2. Процедура начальной регистрации/сертификации может быть защищена за счет аутентификации сообщений от конечного элемента с использованием тех или иных «автономных» (out-of-band) мер (например, передача «из рук в руки»).

4.2.1.3. Место генерации ключа

В данной спецификации говорят о месте «генерации ключа», как о точке, где открытый или закрытый ключ пары впервые появляется в сообщении PKIMessage. Отметим, что это не исключает использования услуг централизованной генерации ключей — на практике пара ключей может генерироваться в любом месте и доставляться конечному элементу RA или CA с использованием (фирменного или стандартизованного) протокола запросов/откликов для генерации ключей16.

Таким образом, местом генерации ключа может являться конечный элемент, RA или CA.

4.2.1.4. Подтверждение успешной сертификации

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

Возможны два варианта — использовать или не использовать подтверждения.

4.2.2. Обязательные схемы

Приведенные выше критерии допускают существование множества схем регистрации/сертификации. Данная спецификация требует от оборудования конечных элементов, CA и RA обязательной поддержки второй из рассмотренных ниже схем (параграф 4.2.2.2). Любой элемент может также дополнительно поддерживать иные схемы.

4.2.2.1. Централизованная схема

В терминах приведенной выше классификации эта схема в некоторых случаях является простейшей из возможных:

  • инициирование выполняется на сертифицирующем CA;
  • не требуется интерактивных сообщений для аутентификации;
  • «генерация ключей» происходит на сертифицирующем CA (см. параграф 4.2.1.3);
  • не требуется подтверждающих сообщений.

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

4.2.2.2. Базовая схема аутентификации

В терминах приведенной выше классификации эта схема включает:

  • инициирование, выполняемое на стороне конечного элемента;
  • требуется аутентификация сообщения;
  • «генерация ключей» происходит на стороне конечного элемента (см. параграф 4.2.1.3);
  • требуется подтверждающее сообщение.

В терминах потока сообщений базовая схема имеет вид:

Конечный элемент

RA/CA

«Автономное» распространение начального ключа аутентификации (IAK17) и эталонного значения (RA/CA -> EE)

Генерация ключа
Запрос на создание сертификата
Защита запроса с помощью IAK

—>>— запрос сертификации —>>—

Проверка запроса
Обработка запроса
Создание отклика

—<<— сертификационнй отклик —<<—

Обработка отклика
Создание подтверждения

—>>— сообщение cert conf —>>—

Проверка подтверждения
Создание отклика

—<<— conf ack (необязательно) —<<—

Обработка отклика

(В тех случаях, когда верификация с использованием подтверждения сертификата не удается, агент RA/CA должен отозвать этот сертификат, если он был опубликован или иным путем сделан доступным).

4.3. Подтверждение владения (POP18) секретным ключом

Для предотвращения некоторых типов атак и обеспечения агентам CA/RA возможности проверить коректность связки между конечным элементом и парой ключей здесь заданы операции управления PKI, которые позволяют конечной точке подтвердить, что ее владение секретным ключом (т. е., возможность использования ключа) соответствует открытому ключу, для которого запрашивается сертификат. Агент CA/RA свободен в выборе способа реализации POP (например, автономные пути или сообщения PKIX-CMP по основному каналу) в своем сертификационном обмене (например, выбор может определяться принятой политикой защиты). Однако от агентов CA/RA требуется выполнение POP тем или иным способом, поскольку в настоящее время используется множество протоколов, не относящихся к PKIX (например, протоколы обмена электронной почтой), которые не проверяют в явной форме привязку секретного ключа к конечному элементу. Пока повсеместно не используется протокол, выполняющий проверку привязки (для ключевых пар подписи, шифрования и согласования ключей), приходиться полагаться на то, что такая привязка проверяется агентом CA/RA. Следовательно, если привязка не проверяется агентом CA/RA, сертификаты в инфраструктуре Internet PKI, по сути, утрачивают свое значение.

POP обеспечивается разными способами в зависимости от типа ключа, для которого запрашивается сертификат. Если ключ может использоваться с разными целями (например, ключ RSA), может применяться любой подходящий метод (например, ключ, который может служить для подписи, а также для других целей, не следует отправлять агенту CA/RA с целью подтверждения владения).

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

4.3.1. Ключи подписи

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

4.3.2. Ключи шифрования

В случае ключей шифрования конечный элемент может предоставлять агенту CA/RA секретный ключ или расшифровывать данные в качестве подтверждения обладания секретным ключом (см. параграф 5.2.8). Расшифровка данных может осуществляться с использованием прямого или косвенного метода.

Метод прямой расшифровки требует от агента RA/CA ввода случайного запроса, на который конечный элемент должен ответить незамедлительно.

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

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

4.3.3. Ключи согласования ключей

Для ключей согласования ключей конечный элемент и элемент управления PKI (т. е., CA или RA) должны организовать разделяемый секретный ключ для подтверждения того, что конечный элемент владеет секретным ключом.

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

4.4. Обновление ключа корневого CA

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

Описанная здесь процедура основана на том, что CA защищает свой новый открытый ключ с помощью предыдущего секретного ключа и наоборот. Таким образом, при обновлении агентом CA пары ключей он должен генерировать два избыточных атрибута cACertificate, если сертификаты делаются доступными с использованием каталогов X.500 (всего генерируется 4 атрибута — OldWithOld, OldWithNew, NewWithOld и NewWithNew).

Когда CA меняет ключевую пару, те элементы, которые обладают старым открытым ключом CA, полученным по автономным каналам (out-of-band), сильнее «страдают» от такой замены. Это будут те конечные элементы, которым требуется доступ к новому открытому ключу CA, защищенному старым секретным ключом CA. Однако эта сложность будет возникать только на ограниченный период (пока конечному элементу не будет доставлен новый открытый ключ CA с использованием «автономного» механизма). Обычно это происходит при истечении срока действия сертификатов данного конечного элемента.

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

Примечание 1. В этой схеме не используется расширений X.509 v3, поэтому она позволяет работать даже с сертификатами версии 1. Использование расширения KeyIdentifier будет повышать эффективность.

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

Примечание 3. Эта схема гарантирует, что конечные элементы будут получать (по «автономным» каналам) новый открытый ключ CA не позднее завершения срока действия имеющегося у конечного элемента сертификата, подписанного старым секретным ключом CA. В других случаях операции обновления ключей и/или сертификата не обязательно будут требовать доставки ключей по «автономным» каналам (это зависит от оборудования конечного элемента).

4.4.1. Действия оператора CA

Для смены ключа CA оператор CA должен выполнить перечисленные ниже операции.

  1. Генерация новой пары ключей;
  2. создание сертификата со старым открытым ключом CA, подписанного новым секретным ключом (сертификат «старый с новым»);
  3. создание сертификата с новым открытым клюом CA, подписанного старым секретным ключом (сертификат «новый со старым»);
  4. создание сертификата с новым открытым ключом CA, подписанного новым секретным ключом (сертификат «новый с новым»);
  5. публикация созданных сертификатов через репозиторий и/или иными способами (например, с использованием сообщений CAKeyUpdAnn);
  6. экспорт нового открытого ключа CA, позволяющий конечным элементам получать этот ключ с использованием «автономных» механизмов (если это нужно).

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

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

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

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

4.4.2. Проверка сертификатов

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

Репозиторий содержит новый и старый открытый ключ

Репозиторий содержит только старый открытый ключ (например, в результате задержки публикации)

PSE содержит новый открытый ключ

PSE содержит старый открытый ключ

PSE содержит новый открытый ключ

PSE содержит старый открытый ключ

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

Случай 1
Стандартная ситуация, когда проверяющая сторона может напрямую верифицировать сертификат без использования репозитория

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

Случай 5
Хотя оператор CA не обновил репозиторий, проверяющая сторона может верифицировать сертификат напрямую (как в случае 1)

Случай 7
Оператор CA не обновил репозиторий и проверка приведет к отказу

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

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

Случай 4
В этом случае проверяющая сторона может напрямую верифицировать сертификат без использования репозитория

Случай 6
Проверяющая сторона будет воспринимать эту ситуацию, как случай 2, и обращаться к репозиторию; верификация приведет в отказу

Случай 8
Хотя оператор CA не обновил репозиторий, проверяющая сторона может верифицировать сертификат напрямую (как в случае 4)

4.4.2.1. Верификация для случаев 1, 4, 5, 8

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

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

4.4.2.2. Верификация для случая 2

В случае 2 проверяющая сторона должна иметь старый открытый ключ CA. Порядок действий проверяющего:

  1. просмотр атрибута caCertificate в репозитории и получение сертификата OldWithNew (определяется на основе срока действия; отметим, что поля субъекта и эмитента должны совпадать);
  2. проверка корректности с использованием нового ключа CA (имеется на проверяющей стороне);
  3. при позитивном результате проверки проверяется сертификат подписавшей стороны с использованием старого ключа CA.

Случай 2 возникает, когда оператор CA эмиттировал сертификат подписавшей стороны, потом сменил ключ и после этого эмиттировал сертификат проверяющей стороны — такая ситуация вполне типична.

4.4.2.3. Верификация для случая 3

В случае 3 проверяющая сторона должна иметь доступ к новому открытому ключу CA. Порядок действий проверяющего:

  1. просмотр атрибута caCertificate в репозитории и получение сертификата NewWithOld (определяется на основе срока действия; отметим, что поля субъекта и эмитента должны совпадать);
  2. проверка корректности с использованием старого ключа CA (имеется на проверяющей стороне);
  3. при позитивном результате проверки проверяется сертификат подписавшей стороны с использованием нового ключа CA.

Случай 2 возникает, когда оператор CA эмиттировал сертификат проверяющей стороны, потом сменил ключ и после этого эмиттировал сертификат подписавшей стороны — такая ситуация вполне типична.

4.4.2.4. Отказ при верификации для случая 6

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

Отметим, что отказ возникает по вине оператора CA.

4.4.2.5. Отказ при верификации для случая 7

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

Отметим, что отказ возникает по вине оператора CA.

4.4.3. Отзыв — смена ключа CA

Как было сказано выше, верификация сертификата усложняется, если агенту CA разрешено менять свои ключи. Это верно также для случаев проверки при отзыве, поскольку агент CA может иметь подпись CRL, выполненную с использованием более нового ключа, нежели для пользовательской среды PSE.

Анализ вариантов для отзыва совпадает с анализом вариантов при проверке сертификата.

5. Структуры данных

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

5.1. Сообщение PKI в целом

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

      PKIMessage ::= SEQUENCE {
         header           PKIHeader,
         body             PKIBody,
         protection   [0] PKIProtection OPTIONAL,
         extraCerts   [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
                          OPTIONAL
     }
     PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage

Поле PKIHeader для многих типов сообщений PKI содержит однотипную информацию.

Поле PKIBody содержит специфическую для данного сообщения информацию.

Если используется поле PKIProtection, оно содержит биты, служащие для защиты сообщения PKI.

Поле extraCerts может содержать сертификаты, которые могут быть полезны для получателя. Например, это поле может использоваться агентом CA или RA для информирования конечного элемента о сертификатах, которые тому потребуются для верификации нового сертификата агента (например, в случае, когда эмиттирующий сертификат конечного элемента агент CA не является коревым CA для данного конечного элемента). Отметим, что это поле не обязательно содержит путь к сертификату — получатель может сортировать это поле, делать из него выборку и т. п.

5.1.1. Заголовок сообщения PKI

Для всех сообщений PKI требуется некоторая информация в заголовке, служащая для адресации и идентификации транзакций. Часть такой информации будет присутствовать также в зависящем от транспорта «конверте». Однако, если сообщение PKI защищено, эта информация также будет защищена (т. е., мы не можем строить предположений о защищенном транспорте).

Для заголовков используется показанная ниже структура данных:

     PKIHeader ::= SEQUENCE {
         pvno                INTEGER     { cmp1999(1), cmp2000(2) },
         sender              GeneralName,
         recipient           GeneralName,
         messageTime     [0] GeneralizedTime         OPTIONAL,
         protectionAlg   [1] AlgorithmIdentifier     OPTIONAL,
         senderKID       [2] KeyIdentifier           OPTIONAL,
         recipKID        [3] KeyIdentifier           OPTIONAL,
         transactionID   [4] OCTET STRING            OPTIONAL,
         senderNonce     [5] OCTET STRING            OPTIONAL,
         recipNonce      [6] OCTET STRING            OPTIONAL,
         freeText        [7] PKIFreeText             OPTIONAL,
         generalInfo     [8] SEQUENCE SIZE (1..MAX) OF
                             InfoTypeAndValue     OPTIONAL
     }
     PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String

Значение поля pvno = 2 соответствует для данной версии спецификации.

Поле sender содержит имя отправителя сообщения PKIMessage. Этого имени (вместе со значениям поля senderKID, если оно присутствует) должно быть достаточно для индикации ключа, который следует использовать для верификации защиты сообщения. Если передающая сторона ничего не знает об отправителе (например, начальное сообщение, когда конечный элемент еще не знает своего отличительного имени DN19, адреса электронной почты, адреса IP и т. д.), в поле sender должно помещаться значение NULL (т. е., SEQUENCE OF для отличительных имен имеет нулевой размер). В таких случаях поле senderKID должно содержать идентификатор (например, номер), показывающий получателю подходящий разделяемый секрет, который можно использовать для верификации этого сообщения.

Поле recipient содержит имя получателя PKIMessage. Это имя (вкупе со значением поля recipKID, если оно присутствует) должно обеспечивать возможность использования для верификации защиты сообщения.

Поле protectionAlg задает алгоритм, используемый для защиты сообщения. Если биты защиты не заданы (отметим, что защита PKIProtection является опциональной), это поле должно быть опущено. При наличии битов защиты это поле должно присутствовать.

Поля senderKID и recipKID служат для индикации ключей, которые используются для защиты сообщения (recipKID обычно требуется лишь в случаях использования для защиты ключей DH20.

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

Поле transactionID в заголовке сообщения позволяет получателю сообщения связать это сообщение с транзакцией. Это требуется для всех транзакций, которые содержат что-либо сверх одной пары «запрос-отклик». Для транзакций, включающих только одну пару «запрос-отклик» клиент может заполнять поле transactionID в запросе. Если сервер получает запрос с установленным полем transactionID, он должен установить в поле transactionID передаваемого отклика то же значение. Если сервер получает запрос без поля transactionID, он может установить значение transactionID в отклике.

Для транзакций, которые включают что-либо сверх одной пары «запрос-отклик» клиенту следует генерировать transactionID для первого запроса. Если сервер получает запрос с установленным полем transactionID, он должен установить в поле transactionID передаваемого отклика то же значение. Если сервер получает запрос без поля transactionID, он должен заполнить в отклике поле transactionID самостоятельно созданным значением идентификатора. Во всех последующих запросах и откликах должно использоваться это значение transactionID. Во всех случаях использования transactionID для клиента недопустимо иметь более одной обрабатываемой в данный момент транзакции с одинаковым значением transactionID (для данного сервера). Серверы по своему усмотрению могут требовать (или не требовать) уникальности значений transactionID для корректной привязки сообщений к соответствующей транзакции. Обычно это означает, что сервер будет требовать уникальности пары {client, transactionID} или даже уникальности transactionID, если он не может различать клиентов на основе информации транспортного уровня. Сервер, получивший в транзакции, требующей более, чем одна пара сообщений «запрос-отклик», первое сообщение, которое содержит значение transactionID, не позволяющее выполнить приведенные выше требования (обычно в результате того, что такое значение transactionID уже используется) должен вернуть клиенту ErrorMsgContent с полем PKIFailureInfo, имеющим значение transactionIdInUse. Клиентам рекомендуется помещать в поле transactionID 128-битовое (псевдо)случайное значение, связанное с началом транзакции, чтобы снизить вероятность совпадения с уже используемым сервером значением transactionID.

Поля senderNonce и recipNonce служат бля защиты сообщения PKIMessage от атак с повторным использованием21. Поле senderNonce обычно содержит 128 битов (псевдо) случайных данных, генерируемых отправителем, а поле recipNonce является копией поля senderNonce из предыдущего сообщения в данной транзакции.

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

Поле freeText может служить для передачи понятных человеку сообщений (на любом языке или множестве языков). Язык, используемый в последовательности первым, является наиболее предпочтительным для откликов.

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

5.1.1.1. ImplicitConfirm

Используется EE для информирования агента CA о нежелании передавать подтверждения для эмиттированных сертификатов.

         implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
         ImplicitConfirmValue ::= NULL

Если CA принимает запрос EE, он должен включить такое же расширение в заголовок PKIHeader своего отклика. Если EE не находит в отклике расширения, он должен передать подтверждение сертификата.

5.1.1.2. ConfirmWaitTime

Используется агентом CA для информирования EE о сроке ожидания подтверждения сертификата перед отзывом того и удалением транзакции.

         confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
         ConfirmWaitTimeValue ::= GeneralizedTime
5.1.2. Тело сообщения PK
PKIBody ::= CHOICE {
    ir       [0]  CertReqMessages,       --Запрос инициализации
    ip       [1]  CertRepMessage,        --Инициализационный отклик
    cr       [2]  CertReqMessages,       --Запрос сертификации
    cp       [3]  CertRepMessage,        --Сертификационный отклик
    p10cr    [4]  CertificationRequest,  --Запрос сертификата PKCS #10
    popdecc  [5]  POPODecKeyChallContent --Запрос pop
    popdecr  [6]  POPODecKeyRespContent, --Отклик pop
    kur      [7]  CertReqMessages,       --Запрос на обновление ключа
    kup      [8]  CertRepMessage,        --Отклик при обновлении ключа
    krr      [9]  CertReqMessages,       --Запрос на восстановление ключа
    krp      [10] KeyRecRepContent,      --Отклик при восстановлении ключа
    rr       [11] RevReqContent,         --Запрос на отзыв
    rp       [12] RevRepContent,         --Отклик при отзыве
    ccr      [13] CertReqMessages,       --Запрос кросс-сертификации
    ccp      [14] CertRepMessage,        --Отклик при кросс-сертификации
    ckuann   [15] CAKeyUpdAnnContent,    --Анонс обновления ключа CA
    cann     [16] CertAnnContent,        --Анонс сертификата
    rann     [17] RevAnnContent,         --Анонс отзыва
    crlann   [18] CRLAnnContent,         --Анонс CRL
    pkiconf  [19] PKIConfirmContent,     --Подтверждение
    nested   [20] NestedMessageContent,  --Вложенное сообщение
    genm     [21] GenMsgContent,         --Сообщение общего назначения
    genp     [22] GenRepContent,         --Отклик общего назначения
    error    [23] ErrorMsgContent,       --Сообщение об ошибке
    certConf [24] CertConfirmContent,    --Подтверждение сертификата
    pollReq  [25] PollReqContent,        --Запрос опроса
    pollRep  [26] PollRepContent         --Отклик при опросе
}

 

Эти типы описаны ниже в параграфе 5.3.

5.1.3. Защита сообщений PKI

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

Для защиты используется структура

PKIProtection ::= BIT STRING

Входной информацией для расчета PKIProtection является DER-представление структуры данных

        ProtectedPart ::= SEQUENCE {
            header    PKIHeader,
            body      PKIBody
        }

Могут возникать ситуации, когда строка битов PKIProtection осознанно не используется в целях защиты сообщения (т. е., это необязательное поле опускается), поскольку для защиты сообщения будут применяться иные средства (внешние по отношению к PKIX). Данная спецификация явно разрешает такое поведение. Примеры внешней защиты включают инкапсуляцию PKCS #7 [PKCS7] и Security Multiparts [RFC1847] для сообщений PKIMessage (или просто PKIBody без тега CHOICE, если для данных заголовка PKIHeader обеспечивается внешний механизм защиты). Отметим, однако, что для большинства таких внешних механизмов требуется наличие у конечной точки сертификата открытого ключа и/или уникального отличительного имени DN, и/или другой информации, связанной с инфраструктурой. В результате такой подход может оказаться неприемлемым для начальной регистрации, восстановления ключей или других процессов с характеристиками «самозагрузки». Для таких случаев может окзаться необходимым использование параметра PKIProtection. В будущем, когда/если внешние механизмы изменятся и смогут поддерживать самозагрузку, использование PKIProtection может стать редким или прекратиться совсем.

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

5.1.3.1. Разделяемый секрет

В этом случае отправитель и получатель совместно владеют некой секретной информацией (для получения секрета используются автономные механизмы или предшествующие операции управления PKI). Поле PKIProtection будет содержать значение MAC, а protectionAlg будет иметь вид (см. также Приложение D.2):

  id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
  PBMParameter ::= SEQUENCE {
    salt                OCTET STRING,
    owf                 AlgorithmIdentifier,
    iterationCount      INTEGER,
    mac                 AlgorithmIdentifier
  }

В приведенном выше protectionAlg значение поля salt (затравка) добавляется в конце ввода разделяемого секрета. После этого алгоритм OWF применяется iterationCount раз, секретное значение с добавленной в конце затравкой служит входными данными для первой итерации, а результат каждой итерации используется в качестве входных данных для следующей итерации. Результат последней итерации (для краткости его называют BASEKEY), размером «H» используется для формирования симметричного ключа. Если алгоритм MAC требует ключа размером K битов и K <= H, будут использоваться K старших битов BASEKEY. Если K > H, все биты BASEKEY используются в качестве H старших битов ключа, OWF(«1» || BASEKEY) образуют следующую группу из H битов ключа, OWF(«2» || BASEKEY) — третью группу и т. д., пока не будет достигнут размер K («N» означает ASCII-представление числа N, а «||» — конкатенацию).

Примечание. Рекомендуется сохранять значения полей параметра PBMParameter неизменными на протяжении одной транзакции (например, ir/ip/certConf/pkiConf) для снижения издержек, связанных с вычислением PasswordBasedMac.

5.1.3.2. Пары ключей DH

Когда отправитель и получатель обладают сертификатами Diffie-Hellman с совместимыми параметрами DH, для защиты сообщения конечный элемент должен генерировать симметричный ключ на основе значений своего секретного ключа DH и открытого DH-ключа получателя сообщения PKI. Поле PKIProtection будет содержать значение MAC, полученное с помощью этого симметричного ключа, а protectionAlg будет иметь вид:

id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}

DHBMParameter ::= SEQUENCE {
    owf                 AlgorithmIdentifier,
    -- Идентификатор алгоритма для необратимой функции (рекомендуется SHA-1)
    mac                 AlgorithmIdentifier
    -- Идентификатор алгоритма MAC (например, DES-MAC, Triple-DES-MAC [PKCS11],
}       -- или HMAC [RFC2104, RFC2202])

В приведенном выше protectionAlg алгоритм OWF применяется к результату расчета по методу Diffie-Hellman. результат OWF (для краткости называется BASEKEY) размером «H» используется для формирования симметричного ключа. Если алгоритм MAC требует ключа размером K битов и K <= H, будут использоваться K старших битов BASEKEY. Если K > H, все биты BASEKEY используются в качестве H старших битов ключа, OWF(«1» || BASEKEY) образуют следующую группу из H битов ключа, OWF(«2» || BASEKEY) — третью группу и т. д., пока не будет достигнут размер K («N» означает ASCII-представление числа N, а «||» — конкатенацию).

5.1.3.3. Подпись

В этом случае отправитель владеет парой ключей цифровой подписи и просто подписывает сообщение PKI. Поле PKIProtection будет содержать значение подписи, а protectionAlg будет содержать идентификатор алгоритма AlgorithmIdentifier для цифровой подписи (например, md5WithRSAEncryption или dsaWithSha-1).

5.1.3.4. Комплексная защита

В случаях, когда конечный элемент передает защищенное сообщение PKI агенту RA, последний может переслать это сообщение агенту CA, добавив к сообщению свою защиту (которая может представлять собой MAC или подпись в зависимости от сертификатов, согласованных между RA и CA). Это осуществляется путем вложения сообщения от конечного элемента целиком в новое сообщение PKI. Используемая для этого структура показана ниже.

NestedMessageContent ::= PKIMessages

(использование сообщений PKIMessage в форме SEQUENCE OF PKIMessage позволяет агенту RA обрабатывать в пакетном режиме запросы нескольких EE в форме одного нового сообщения; для простоты все сообщения такого пакета должны быть однотипными — например, ir). Если RA хочет изменить сообщение (сообщения) тем или иным способом (например, добавить новые значения полей или расширения), он может создать свою желаемую структуру PKIBody. Исходное сообщение PKIMessage от EE может быть включено в поле generalInfo заголовка PKIHeader (например, для случаев, когда CA пожелает проверить POP или другие данные из исходного сообщения). Поле infoType, используемое в таких ситуациях имеет форму {id-it 15} (см. параграф 5.3.19, где описаны значения id-it), а infoValue представляет собой сообщения PKIMessage (содержимое должно быть представлено в том же порядке, как располагаются запросы в PKIBody).

5.2. Структуры данных общего назначения

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

5.2.1. Содержимое запрашиваемого сертификата

Различные управляющие сообщения PKI требуют, чтобы инициатор сообщения указывал некоторые поля, присутствие которых в сертификате обяязательно. Структура данных CertTemplate позволяет конечному элементу или агенту RA зададать свои требования к сертификату. Структура CertTemplate идентична структуре Certificate, но некоторые поля не являются обязательными.

Отметим, что даже при полном задании инициатором требований к сертификату, агент CA может менять поля в эмиттируемом сертификате. Если измененный сертификат неприемлем для запрашивающей стороны, та должна вернуть сообщение certConf, не включающее данный сертификат (через CertHash) или включающее его (через CertHash) со статусом rejected. Определение и описание применения CertHash и certConf дано в параграфе 5.3.18.

См. Приложение C и [CRMF], где описан синтаксис CertTemplate.

5.2.2. Зашифрованные значения

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

Синтаксис EncryptedValue описан в [CRMF].

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

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

5.2.3. Коды состояний и информация об отказах для сообщений PKI

Все сообщения-отклики будут включать ту или иную информацию о состоянии. Ниже перечислены коды состояний.

PKIStatus ::= INTEGER {
    accepted               (0), -- воспринято
    grantedWithMods        (1), -- представлено с Mods
    rejection              (2), -- отвергнуто
    waiting                (3), -- ожидание
    revocationWarning      (4), -- предупреждение об отзыве
    revocationNotification (5), -- уведомление об отзыве
    keyUpdateWarning       (6)  -- предупреждение о обновлении ключа
}

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

.

        PKIFailureInfo ::= BIT STRING {
            badAlg              (0),
            badMessageCheck     (1),
            badRequest          (2),
            badTime             (3),
            badCertId           (4),
            badDataFormat       (5),
            wrongAuthority      (6),
            incorrectData       (7),
            missingTimeStamp    (8),
            badPOP              (9),
            certRevoked         (10),
            certConfirmed       (11),
            wrongIntegrity      (12),
            badRecipientNonce   (13),
            timeNotAvailable    (14),
            unacceptedPolicy    (15),
            unacceptedExtension (16),
            addInfoNotAvailable (17),
            badSenderNonce      (18),
            badCertTemplate     (19),
            signerNotTrusted    (20),
            transactionIdInUse  (21),
            unsupportedVersion  (22),
            notAuthorized       (23),
            systemUnavail       (24),
            systemFailure       (25),
            duplicateCertReq    (26)
        }

        PKIStatusInfo ::= SEQUENCE {
            status        PKIStatus,
            statusString  PKIFreeText     OPTIONAL,
            failInfo      PKIFailureInfo  OPTIONAL
        }

 

5.2.4. Идентификация сертификата

Для идентификации отдельного сертификата служит структура данных CertId.

Синтаксис CertId описан в [CRMF].

5.2.5. «Автономный» открытый ключ корневого CA

Каждый корневой агент CA должен быть способен опубликовать свой текущий открытый ключ с помощью того или иного «автономного» (out-of-band) механизма. Хотя рассмотрение таких механизмов выходит за пределы данного документа, здесь определены структуры данных, которые могут поддерживать такие механизмы.

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

OOBCert ::= Certificate

Для полей этого сертификата вводится ряд ограничений:

  • сертификат должен быть самомподписанным (т. е., подпись должна быть проверяемой с использованием поля SubjectPublicKeyInfo);
  • поля subject и issuer должны быть идентичны;
  • если subject = NULL, должны присутствовать оба расширения subjectAltNames и issuerAltNames, а их значения должны совпадать;
  • значения всех остальных расширений должны быть применимыми к самоподписанным сертификатам (например, идентификаторы ключей для subject и issuer должны совпадать).
        OOBCertHash ::= SEQUENCE {
            hashAlg     [0] AlgorithmIdentifier     OPTIONAL,
            certId      [1] CertId                  OPTIONAL,
            hashVal         BIT STRING
        }

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

5.2.6. Опции архивирования

Запрашивающая сторона может указывать свое пожелание к PKI об архивировании секретного ключа с использованием структуры PKIArchiveOptions.

Синтаксис PKIArchiveOptions описан в [CRMF].

5.2.7. Публикация данных

Запрашивающая сторона может указывать свое пожелание к PKI о публикации сертификата с использованием структуры PKIPublicationInfo.

Синтаксис PKIPublicationInfo описан в [CRMF].

5.2.8. Структуры PoP

Если запрос сертификата сделан для пары ключей, используемой при подписи (т. е., запрашиватеся сертификат для верификации) владение секретным ключом подписи демонстрируется с помощью структуры POPOSigningKey.

Синтаксис POPOSigningKey описан в Приложении C и [CRMF], но следует отметить, что данная спецификация накладывает некоторые условия на семантику POPOSigningKeyInput.

        POPOSigningKeyInput ::= SEQUENCE {
            authInfo            CHOICE {
                sender              [0] GeneralName,
                publicKeyMAC            PKMACValue
            },
            publicKey           SubjectPublicKeyInfo
        }

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

5.2.8.1. Включение секретного ключа

Включение секретного ключа (в зашифрованном виде) в сообщение CertRequest (в поле thisMessage структуры POPOPrivKey (см. Приложение C) или PKIArchiveOptions в зависимости от того, требуется ли также архивирование секретного ключа).

5.2.8.2. Косвенный метод

Агент CA возвращает зашифрованный сертификат взамен обычного (т. е., сертификат шифруется со случайным значением симметричного ключа, а этот ключ шифруется с использованием открытого ключа, для которого сделан запрос сертификата) — этот метод ранее в параграфе 4.3.2 назван косвенным. Конечный элемент подтверждает агенту CA свое знание секретного ключа дешифровки путем включения корректного значения CertHash для данного сертификата в сообщение certConf. Это служит демонстрацией POP, поскольку EE может корректно рассчитать значение CertHash только в том случае, когда имеется возможность восстановить сертификат, а для этого требуется расшифровать симметричный ключ, используя соответствующий секретный ключ. Очевидно, что для того, чтобы такой механизм работал, агенту CA недопустимо публиковать сертификат, пока не будет получено сообщение certConf (в случае использования certHash для демонстрации POP). Более подробная информация приведена в параграфе 5.3.18.

5.2.8.3. Протокол «вызов-отклик»

Конечный элемент использует протокол «вызов-отклик23» (на основе описанных ниже сообщений POPODecKeyChall и POPODecKeyResp) между структурами данных CertReqMessages и CertRepMessage — этот метод в параграфе 4.3.2 назван прямым24. Полная схема взаимодействия показана на рисунке справа (отметим, что сообщение req’ не всегда инкапсулирует req, как вложенное сообщение.

                   EE            RA            CA
                    ---- req ---->
                    <--- chall ---
                    ---- resp --->
                                  ---- req' --->
                                  <--- rep -----
                                  ---- conf --->
                                  <--- ack -----
                    <--- rep -----
                    ---- conf --->
                    <--- ack -----

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

                   EE            RA            CA
                    ---- req ---->
                    <--- chall ---
                    ---- resp --->
                                  ---- req' --->
                                  <--- rep -----
                    <--- rep -----
                    ---- conf --->
                                  ---- conf --->
                                  <--- ack -----
                    <--- ack -----

Если сертификат запрашивается для пары ключей KAK25, в процедуре POP может использоваться любой из трех описанных выше способов для пары ключей шифрования с некоторыми изменениями: (1) текст в скобках для параграфа 5.2.8.2 меняется на «(т. е., сертификат шифруется симметричным ключом, полученным из секретного ключа KAK агента CA и открытого ключа, для которого делается запрос сертификата)»; (2) текст в первых скобках приведенного ниже описания поля challenge26 меняется на «(с использованием PreferredSymmAlg (см. параграф 5.3.19.4 и Приложение E.5) и симметричного ключа, полученного из секретного ключа KAK агента CA и открытого ключа, для которого делается запрос сертификата)». В дополнение к этому для POP можно использовать структуру POPOSigningKey, описанную в [CRMF] (поле alg имеет значение DHBasedMAC, а поле signature — MAC), в качестве четвертого варианта, если CA уже имеет сертификат D-H, известный EE.

Сообщения «вызов-отклик» процедуры POP для секретного ключа дешифровки описаны ниже (см. также стр. 404 документа [MvOV97]). Отметим, что этот обмен «вызов-отклик» связан с предшествующим сообщением для запроса сертификата (а также последующим откликом на такой запрос и подтверждением) через идентификатор transactionID в заголовке PKIHeader и защиту (MAC или подпись), применяемую к сообщению PKIMessage.

        POPODecKeyChallContent ::= SEQUENCE OF Challenge
        Challenge ::= SEQUENCE {
            owf                 AlgorithmIdentifier  OPTIONAL,
            witness             OCTET STRING,
            challenge           OCTET STRING
        }

Отметим, что размер Rand должен соответствовать требованиям шифрования с открытым ключом запрашивающей стороны. С учетом того, что размер int обычно не превышает 64 битов, остается более 100 байтов для поля sender, при использовании модуля в 1024 бита. Если в той или иной среде имена слишком велики и не могут поместиться (например, слишком длинные имена DN), следует использовать вмещающуюся часть (она должна обеспечивать получателю возможность однозначной трактовки сокращения).

POPODecKeyRespContent ::= SEQUENCE OF INTEGER

5.2.8.4. Обзор опций PoP

В этом параграфе описано несколько опций, связанных с методами POP. Список методов (сокращение SK27 означает ключ подписи, EK28 — ключ шифрования, KAK — ключ согласования ключей) приведен ниже.

         RAVerified;
         SKPOP;
         EKPOPThisMessage;
         KAKPOPThisMessage;
         KAKPOPThisMessageDHMAC;
         EKPOPEncryptedCert;
         KAKPOPEncryptedCert;
         EKPOPChallengeResp; 
         KAKPOPChallengeResp.

С учетом этого массива опций возникает вопрос — как конечный элемент может узнать набор опций, поддерживаемых агентом CA/RA (т. е., понять, какие опции могут применяться при запросе сертификатов). Приведенные ниже рекомендации проясняют этот вопрос для разработчиков EE.

RAVerified. Выбор этой опции не определяется EE — агент RA использует эту опцию тогда и только тогда, когда он проверяет POP перед пересылкой запроса агенту CA, следовательно, EE не может выбирать этот метод.

SKPOP. Если EE имеет пару ключей подписи, этот вариант является единственным методом POP, заданным данной спецификацией для использования при запросе соответствующего сертификата.

EKPOPThisMessage и KAKPOPThisMessage. Конечный элемент сам принимает решение о предоставлении своего секретного ключа агенту CA/RA. Если EE считает нужным открыть свой ключ, этот вариант является единственным методом POP, заданным данной спецификацией для решения этой задачи (выбор одного из двух методов будет определяться типом ключевой пары).

KAKPOPThisMessageDHMAC. EE может использовать этот метод только при выполнении двух условий — (1) агент CA имеет сертификат DH, подходящий для этой цели, и (2) EE уже имеет копию этого сертификата. При выполнении обоих условий этот метод поддерживается явно и может быть использован конечным элементом.

EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp, KAKPOPChallengeResp. EE помещает одну из этих опций (в зависимости от предпочтений и типа ключа) в поле subsequentMessage запросного сообщения. Тем самым, EE не выполняет процедуры POP, а просто указывает желаемый метод. Следовательно, если CA/RA возвращает сообщение об ошибке badPOP, конечный элемент повторяет запрос с использованием другого метода POP в сообщении subsequentMessage. Отметим, однако, что данная спецификация поощряет использование методов EncryptedCert и, более того, говорит, что «вызов-отклик» будет применяться обычно при вовлечении RA в верификацию POP. Таким образом, EE следует поддерживать возможность принятия интеллектуального решения о выборе одного из этих методов POP в сообщении-запросе.

5.3. Структуры данных, связанные с операциями

5.3.1. Запрос инициализации

Запрос Initialization содержит в качестве PKIBody структуру данных CertReqMessages, которая задает запрашиваемый(е) сертификат(ы). Обычно поля SubjectPublicKeyInfo, KeyId и Validity являются шаблонами, которые могут быть применены к каждому сертификату (см. профили в Приложении D). Этот тип сообщений предназначен для использования при первичной инициализации в PKI.

Синтаксис CertReqMessages описан в Приложении C и документе [CRMF].

5.3.2. Отклик при инициализации

Отклик Initialization содержит в качестве PKIBody структуру данных CertRepMessage, которая включает поле PKIStatusInfo для каждого из запрошенных сертификатов, а также может включать секретный ключ (обычно он шифруется сеансовым ключом, который, в свою очередь, шифруется ключом protocolEncrKey).

Синтаксис CertRepMessage описан в параграфе 5.3.4. Отметим, что при использовании для защиты сообщений PKI разделяемого секрета (см. параграф 5.1.3) любому сертификату, передаваемому в поле caPubs, инициатор может доверять непосредственно, как сертификату корневого CA.

5.3.3. Запрос сертификации

Запросное сообщение Certification содержит в качестве PKIBody структуру данных CertReqMessages, которая задает запрашиваемые сертификаты. Это сообщение предназначено для использвания действующими элементами PKI, когда им нужны дополнительные сертификаты.

Синтаксис CertReqMessages описан в Приложении C и документе [CRMF].

В дополнение к этому PKIBody может представлять собой структуру данных CertificationRequest (эта структура полностью в формате ASN.1 в документе [PKCS10]). Данная структура может потребоваться при запросах сертификатов для ключей подписи при необходимости организации взаимодействия с унаследованными системами, но использовать ее без крайней необходимости настоятельно не рекомендуется.

5.3.4. Отклик при сертификации

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

     CertRepMessage ::= SEQUENCE {
         caPubs          [1] SEQUENCE SIZE (1..MAX) OF Certificate
                             OPTIONAL,
         response            SEQUENCE OF CertResponse
     }

     CertResponse ::= SEQUENCE {
         certReqId           INTEGER,
         status              PKIStatusInfo,
         certifiedKeyPair    CertifiedKeyPair    OPTIONAL,
         rspInfo             OCTET STRING        OPTIONAL
         -- analogous to the id-regInfo-utf8Pairs string defined
         -- for regInfo in CertReqMsg [CRMF]
     }

     CertifiedKeyPair ::= SEQUENCE {
         certOrEncCert       CertOrEncCert,
         privateKey      [0] EncryptedValue      OPTIONAL,
         -- see [CRMF] for comment on encoding
         publicationInfo [1] PKIPublicationInfo  OPTIONAL
     }

     CertOrEncCert ::= CHOICE {
         certificate     [0] Certificate,
         encryptedCert   [1] EncryptedValue
     }

В каждой структуре CertResponse может присутствовать только одно из полей (в зависимости от статуса результата) — failInfo (в PKIStatusInfo) или certificate (в CertifiedKeyPair). Для некоторых значений статуса (например, waiting — ожидание) не будет присутствовать ни одного из этих полей.

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

5.3.5. Содержимое запроса на обновление ключа

Для запросов на обновление ключей используется синтаксис CertReqMessages. Обычно SubjectPublicKeyInfo, KeyId и Validity являются шаблонами полей, которые могут быть представлены для каждого обновляемого ключа. Этот тип сообщений предназначен для запроса на обновление действующих (не отозванных и не просроченных) сертификатов (поэтому иногда его называют обновлением сертификатов — Certificate Update). Обновление является заменой сертификата, содержащей новый новый или текущий открытый ключ субъекта (второй вариант может быть неприемлемым для некоторых сред).

Синтаксис CertReqMessages описан в Приложении C и документе [CRMF].

5.3.6. Содержимое отклика при обновлении ключа

Для откликов на запрос обновления ключей используется синтаксис CertRepMessage. Отклик идентичен отклику при инициализации.

Синтаксис CertRepMessage описан в параграфе 5.3.4.

5.3.7. Содержимое запроса на восстановление ключа

Для запросов на восстановление ключей используется синтаксис, аналогичный инициализационному запросу CertReqMessages. Обычно поля SubjectPublicKeyInfo и KeyId являются шаблонами, которые могут быть использованы для открытого ключа подписи, для которого запрашивается сертфикат (см. также Приложение D).

Синтаксис CertReqMessages описан в Приложении C и документе [CRMF]. Отметим, что при наличии необходимости в истории ключа запрашивающая сторона должна включить в сообщение элемент управления Protocol Encryption Key.

5.3.8. Содержимое отклика при восстановлении ключа

Синтаксис для откликов при восстановлении ключей показан ниже. Для некоторых значений статуса (например, waiting — ожидание) все необязательные поля могут отсутствовать.

    KeyRecRepContent ::= SEQUENCE {
        status          PKIStatusInfo,
        newSigCert  [0] Certificate                   OPTIONAL,
        caCerts     [1] SEQUENCE SIZE (1..MAX) OF
                                     Certificate      OPTIONAL,
        keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
                                     CertifiedKeyPair OPTIONAL
    }

 

5.3.9. Содержимое запроса на отзыв

При запросе на отзыв сертификата (или нескольких сертификатов) используется приведенная ниже структура данных. Имя запрашивающей стороны присутствует в структуре PKIHeader.

    RevReqContent ::= SEQUENCE OF RevDetails

    RevDetails ::= SEQUENCE {
        certDetails         CertTemplate,
        crlEntryDetails     Extensions       OPTIONAL
    }

5.3.10. Содержимое отклика при отзыве

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

     RevRepContent ::= SEQUENCE {
         status        SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
         revCerts  [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
         crls      [1] SEQUENCE SIZE (1..MAX) OF CertificateList
                       OPTIONAL
     }

5.3.11. Содержимое запроса кросс-сертификата

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

Синтаксис CertReqMessages описан в Приложении C и документе [CRMF].

5.3.12. Содержимое отклика при кросс-сертификации

В откликах при кросс-сертификации используется такой же синтаксис (CertRepMessage), при обычных откликах на запрос сертификата, но защифрованный секретный ключ в них передаваться не может.

Синтаксис CertRepMessage описан в параграфе 5.3.4.

5.3.13. Содержимое анонса обновления ключа CA

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

    CAKeyUpdAnnContent ::= SEQUENCE {
       oldWithNew         Certificate,
       newWithOld         Certificate,
       newWithNew         Certificate
    }

5.3.14. Анонсирование сертификата

Описанная здесь структура может применяться для анонсирования существования сертификатов.

Отметим, что это сообщение предназначено для использования в тех случаях (если они возникают), когда нет заранее созданного метода публикации сертификатов, и не предназначено для применения в тех случаях, когда имеется метод публикации сертификатов (например, X.500).

CertAnnContent ::= Certificate

5.3.15. Анонсирование отзыва

Когда агент CA отзывает конкретный сертификат или близится срок отзыва, агент может анонсировать это (возможно, грядущее) событие.

        RevAnnContent ::= SEQUENCE {
            status              PKIStatus,
            certId              CertId,
            willBeRevokedAt     GeneralizedTime,
            badSinceDate        GeneralizedTime,
            crlDetails          Extensions  OPTIONAL
        }

CA может использовать этот анонс для предупреждения (или уведомления) субъекта, чей сертификат отзывается (или будет отозван). Обычно это происходит в тех случаях, когда запрос на отзыв исходит не от субъекта, чей сертификат будет отзываться.

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

5.3.16. Анонсирование CRL

Когда агент CA создает новый список CRL (или набор CRL) для анонсирования этого события может использоваться приведенная ниже структура.

CRLAnnContent ::= SEQUENCE OF CertificateList

5.3.17. Содержимое подтверждения PKI

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

PKIConfirmContent ::= NULL

Использовать эти сообщения для подтверждения сертификатов не рекомендуется, следует вместо этого применять certConf. При получении PKIConfirm в отклике для сертификата получатель может трактовать его, как certConf для подтверждения восприятия всех сертификатов.

5.3.18. Содержимое подтверждения сертификата

Эта структура данных используется клиентом для передачи агенту CA/RA подтверждения о восприятии или отказе от сертификата.

         CertConfirmContent ::= SEQUENCE OF CertStatus

         CertStatus ::= SEQUENCE {
            certHash    OCTET STRING,
            certReqId   INTEGER,
            statusInfo  PKIStatusInfo OPTIONAL
         }

 

Для любого конкретного значения CertStatus опущенное поле statusInfo показывает восприятие указанного сертификата. Кроме того, могут явно указываться (как для восприятия, так и для отказа) в поле statusInfo дополнительные сведения о результате (например, для системы аудита агента CA/RA).

Внутри CertConfirmContent отсутствие структуру CertStatus, соответствующей сертификату, представленному в предшествующем отклике, говорит о том, что сертификат отвергнут. Поэтому может использоваться пустое значение CertConfirmContent (SEQUENCE нулевого размера) для индикации отказа от всех представленных сертификатов. В параграфе 5.2.8 (п. 2) приведено обсуждение поля certHash применительно к подтверждению владения.

5.3.19. Содержимое сообщений PKI общего назначения

     InfoTypeAndValue ::= SEQUENCE {
         infoType               OBJECT IDENTIFIER,
         infoValue              ANY DEFINED BY infoType  OPTIONAL
     }
     -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
     GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
5.3.19.1. Сертификат шифрования протокола CA

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

      GenMsg:    {id-it 1}, < absent >
      GenRep:    {id-it 1}, Certificate | < absent >

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

5.3.19.2. Типы ключевых пар для подписи

Может использоваться конечным элементом для получения списка алгоритмов цифровой подписи (например, RSA, DSA), для которых агент CA будет сертифицировать значения открытых ключей субъекта. Отметим, что для целей обмена сообщениями значения rsaEncryption и rsaWithSHA1, например, рассматриваются, как эквивалентные; вопрос можно сформулировать так: «Желает ли CA сертифицировать открытый ключ RSA?»

      GenMsg:    {id-it 2}, < absent >
      GenRep:    {id-it 2}, SEQUENCE SIZE (1..MAX) OF
5.3.19.3. Типы ключевых пар для шифрования/согласования ключей

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

      GenMsg:    {id-it 3}, < absent >
      GenRep:    {id-it 3}, SEQUENCE SIZE (1..MAX) OF
                            AlgorithmIdentifier
5.3.19.4. Предпочтительный симметричный алгоритм

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

      GenMsg:    {id-it 4}, < absent >
      GenRep:    {id-it 4}, AlgorithmIdentifier
5.3.19.5. Обновление ключевой пары CA

Может использоваться агентом CA для анонсирования обновления ключа.

GenMsg: {id-it 5}, CAKeyUpdAnnContent
5.3.19.6. CRL

Может использоваться клиентом для получения копии последнего списка отозванных сертификатов (CRL).

GenMsg: {id-it 6}, < absent >
GenRep: {id-it 6}, CertificateList
5.3.19.7. Неподдерживаемые идентификаторы объекта

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

GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
5.3.19.8. Параметры ключевой пары

Может использоваться конечным элементом для запроса параметров домена, применяемых при генерации ключевых пар для некоторых алгоритмов с открытым ключом. Может служить, например, для запроса подходящих значений P, Q и G при генерации ключа DH/DSA или для запроса общеизвестных эллиптических кривых.

GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (идентификатор объекта в алгоритме)
GenRep: {id-it 11}, AlgorithmIdentifier | < absent >

Отсутствие infoValue в GenRep показывает, что заданный в GenMsg алгоритм не поддерживается.

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

5.3.19.9. Пароль для отзыва

Может использоваться конечным элементом для передачи пароля агенту CA/RA с целью заверения последующего запроса на отзыв (в случаях, когда соответствующий секретный ключ уже невозможно использовать для заверения запроса). Дополнительная информация об использовании этого механизма приведена в Приложении B.

GenMsg: {id-it 12}, EncryptedValue
GenRep: {id-it 12}, < absent >
5.3.19.10. ImplicitConfirm

Определение и описание применения {id-it 13} дано в параграфе 5.1.1.1.

5.3.19.11. ConfirmWaitTime

Определение и описание применения {id-it 14} дано в параграфе 5.1.1.2.

5.3.19.12 Исходное сообщение PKIMessage

Определение и описание применения {id-it 15} дано в параграфе 5.1.3.

5.3.19.13. Поддерживаемые теги языка

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

GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String

5.3.20. Содержимое отклика PKI общего назначения

GenRepContent ::= SEQUENCE OF InfoTypeAndValue

Примеры GenRep, которые могут поддерживаться, включают те, что перечислены в подпараграфах параграфа 5.3.19.

5.3.21. Содержимое сообщений об ошибках

Эта структура данных может использоваться EE, CA и RA для передачи информации об ошибке.

    ErrorMsgContent ::= SEQUENCE {
        pKIStatusInfo          PKIStatusInfo,
        errorCode              INTEGER           OPTIONAL,
        errorDetails           PKIFreeText       OPTIONAL
    }

Это сообщение может генерироваться в любой момент на протяжении транзакции PKI. Когда клиент передает такой запрос, сервер должен возвратить в ответ сообщение PKIConfirm или другое сообщение ErrorMsg, если какая-либо часть заголовка является некорректной. Обе стороны должны трактовать такое сообщение, как завершение транзакции (если таковая происходит).

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

5.3.22. Запрос и отклик при опросе

Эта пара сообщений предназначена для обслуживания ситуаций, когда клиенту нужно опросить сервер для определения статуса незавершенных транзакций ir, cr или kur (т. е., при «ожидании» получения PKIStatus).

    PollReqContent ::= SEQUENCE OF SEQUENCE {
        certReqId    INTEGER }

    PollRepContent ::= SEQUENCE OF SEQUENCE {
        certReqId    INTEGER,
        checkAfter   INTEGER,  -- time in seconds
        reason       PKIFreeText OPTIONAL }

Ниже перечислены ситуации, когда используется опрос и способы применения. Предполагается, что во время транзакции может быть передано множество сообщений certConf. Одно такое сообщение будет передаваться в ответ на каждое сообщение ip, cp или kup, содержащее CertStatus для эмиттированного сертификата.

                           СТАРТ
                             |
                             v
                        Передача ir
                             | ip
                             v
                      Проверка статуса
                        возвращенных <-----------------------+
                        сертификатов                         |
                             |                               |
   +------------------------>|<------------------+           |
   |                         |                   |           |
   |        (issued)         v       (waiting)   |           |
Добавл. <--------- Проверка CertResponse -----> Добавление в |
в список          для каждого сертификата          список    |
подтвержд.                   /                    ожидания   |
                            /                                |
           (список подтв.) /     (пустой список подтв.)      |
                          /                     ip           |
                         /                 +----------------+
(пустой список ожидания)/                  |    pRep
  ФИНИШ <---- Передача certConf    Передача pReq----->Ожидание
                     |                 ^   ^               |
                     |                 |   |               |
                     +-----------------+   +---------------+
                      (список ожидания)
  1. В ответ на сообщение ip, cp или kup конечный элемент будет передавать certConf для всех эмиттированных сертификатов и, вслед за этим, pollReq для всех ожидаемых сертификатов.
  2. В ответ на pollReq агент CA/RA будет возвращать ip, cp или kup, если один или несколько ожидаемых сертификатов уже готовы; в противном случае будет возвращаться pollRep.
  3. Если EE получает pollRep, он будет ждать в течение времени не менее заданного полем checkAfter перед отправкой другого pollReq.
  4. Если сообщение ip, cp или kup получено в ответ на pollReq, оно трактуется так же, как при начальном отклике.

В приведенном ниже примере конечный элемент включает для сертификата в один запрос.

Этап

Конечный элемент

PKI

1

Форматирование ir

2

->

ir

->

3

Обработка ir

4

При необходимости участие оператора для обоих сертификатов

5

<-

ip

<-

6

Обработка ip

7

Форматирование pReq

8

->

pReq

->

9

Проверка статуса запросов на сертификаты

10

Сертификаты не готовы

11

Форматирование pRep

12

<-

pRep

<-

13

Ожидание

14

Форматирование pReq

15

->

pReq

->

16

Проверка статуса запросов на сертификаты

17

Один сертификат готов

18

Форматирование ip

19

<-

ip

<-

20

Обработка ip

21

Форматирование certConf

22

->

certConf

->

23

Обработка certConf

24

Форматирование ack

25

<-

pkiConf

<-

26

Форматирование pReq

->

pReq

->

27

Проверка статуса запросов на сертификаты

28

Сертификат готов

29

Форматирование ip

30

<-

ip

<-

31

Обработка ip

32

Форматирование certConf

33

->

certConf

->

34

Обработка certConf

35

Форматирование ack

36

<-

pkiConf

<-

6. Обязательные функции управления PKI

Некоторые из функций управления PKI, обозначенные в параграфе 3.1, более подробно описываются здесь.

В этом разделе рассматриваются функции, которые являются обязательными в том смысле, что каждая реализация конечного элемента и агента CA/RA должна обеспечивать соответствующую функциональность. Этот раздел, по сути, является профилем функциональности управления PKI, который должен поддерживаться. Отметим, однако, что функции управления, описанные в этом разделе, не требуется реализовывать с использованием описанных в разделе 5 сообщений PKI, если в данной среде доступны другие варианты (см. Приложение D, где описаны профили сообщений PKIMessage, которые должны поддерживаться).

6.1. Инициализация корневого CA

[Определение корневого CA приведено в параграфе 3.1.1.2 этого документа.]

Вновь созданный корневой агент CA должен выполнить «само-сертификацию», которая обеспечивается структурой Certificate с профилем, определенным для сертификата newWithNew, эмиттируемого вслед за обновлением ключа корневого CA.

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

Для передачи оттиска используется структура данных OOBCertHash.

6.2. Обновление ключа корневого CA

Ключи CA (как и все другие ключи) имеют конечное время жизни и должны периодически обновляться. Агент CA может эмиттировать сертификаты NewWithNew, NewWithOld и OldWithNew (см. параграф 4.4.1), чтобы помочь существующим конечным элементам, которые используют текущий самоподписанный сертификат CA (OldWithOld), в защищенном переходе к новому самоподписанному сертификату CA (NewWithNew), а также новым конечным элементам, которые будут владеть сертификатом NewWithNew, в защищенном получении сертификата OldWithOld для верификации существующих данных.

6.3. Инициализация второстепенного CA

[Определение термина «второстепенный агент CA» приведено выше в параграфе 3.1.1.2.]

С точки зрения протоколов управления PKI инициализация второстепенного агента CA не отличается от инициализации конечного элемента. Единственное различие заключается в том, что второстепенный агент CA должен также создавать начальный список отзыва.

6.4. Создание CRL

Перед эмиттированием любого сертификата вновь созданный агент CA (который эмиттирует CRL) должен создать «пустые» версии каждого списка, который он будет периодически создавать.

6.5. Запрос информации PKI

Когда элемент PKI (CA, RA или EE) хочет получить информацию о текущем статусе CA, он может передать агенту CA запрос на такую информацию.

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

Если для запроса и предоставления информации PKI используются сообщения PKIMessage, запрос должен представлять собой сообщение GenMsg, отклик должен быть сообщением GenRep, а информация об ошибке должна быть сообщением Error. Эти сообщения защищают с использованием MAC на основе разделяемого секрета (т. е., PasswordBasedMAC) или иных заверенных механизмов (если конечный элемент имеет действующий сертификат).

6.6. Кросс-сертификация

Запрашивающий CA — это агент CA, который является субъектом кросс-сертификата; отвечающим CA будет агент, эмиттирующий кросс-сертификат.

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

6.6.1. Односторонняя схема «запрос-отклик»

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

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

Описание.

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

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

Запрашивающий агент CA инициирует обмен путем генерации запроса на кросс-сертификат (ccr29) со «свежим» случайным значением (случайное значение запрашивающей стороны). Сообщение ccr передается отвечающему агенту CA. Поля этого сообщения защищают от изменения с помощью кода авторизации на основе MAC.

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

При получении сообщения ccp запрашивающий агент CA проверяет это сообщение (включая полученное в нем случайное число) и MAC. После этого запрашивающий CA отвечает сообщением certConf. Поля этого сообщения защищаются от изменения с помощью кода авторизации на основе MAC. Запрашивающий агент CA может записать полученный сертификат в репозиторий (Repository) для использования в последствии при создании пути для сертификата.

При получении сообщения certConf отвечающий агент CA проверяет это сообщение и MAC, а потом возвращает подтверждение, используя для этого сообщение PKIConfirm. Он может также опубликовать сертификат запрашивающей стороны, чтобы упростить в будущем создание пути.

Примечания.

  1. Сообщение ccr должно содержать «полный» запрос сертификата, т. е., запрашивающим агентом должны быть заданы все поля за исключением порядкового номера (включая, например, расширение BasicConstraints).
  2. В сообщение ccp следует включать сертификат верификации отвечающего CA; при наличии такого сертификата запрашивающий агент CA должен проверить его (например, с помощью «автономного» механизма).

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

6.7. Инициализация конечного элемента

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

  • получение информации PKI;
  • автономная верификация открытого ключа корневого агента CA.

(к возможным этапам инициализации относятся также получение информации об условиях доверия и/или автономная верификация открытых ключей других агентов CA).

6.7.1. Получение информации PKI

Требуемая информация включает:

  • открытый ключ текущего корневого CA;
  • (если сертифицирующий CA не является корневым) сертификационный путь от корневого CA к сертифицирующему агенту CA вместе с соответствующими списками отзыва;
  • алгоритмы, поддерживаемые сертифицирующим CA, и их параметры для каждого варианта применения.

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

Требуемая информация может быть получена в соответствии с описанием в параграфе 6.5.

6.7.2. «Автономная» верификация ключа корневого CA

Конечный элемент может получить открытый ключ своего корневого CA защищенным путем. Одним из возможных способов служит предоставление конечному элементу самосертифицированного оттиска CA тем или иным «автономным» путем. Тогда конечный элемент сможет безопасно воспользоваться самосертификацией CA.

Дополнительная информация приведена в параграфе 6.1.

6.8. Запрос сертификата

Инициализированный конечный элемент может запросить дополнительный сертификат в любой момент (и с любой целью). Такой запрос осуществляется с использованием сообщения cr31. Если конечный элемент уже владеет ключевой парой для подписи (с соответствующим сертификатом верификации), сообщение cr обычно защищается с использованием цифровой подписи. Агент CA возвращает новый сертификат (при успешном выполнении запроса) в сообщении CertRepMessage.

6.9. Обновление ключа

Когда срок действия ключевой пары близок к завершению, соответствующий конечный элемент может запросить обновление ключей — т. е., он может запросить у агента CA выпуск нового сертификата для новой ключевой пары (или, в некоторых ситуациях, нового сертификата для прежней пары ключей). Запрос выполняется с помощью сообщения kur32 (в некоторых средах это называют операцией обновления сертификата — Certificate Update). Если конечный элемент уже владеет ключевой парой для подписи (с соответствующим сертификатом верификации), сообщение kur обычно защищается с использованием цифровой подписи. Агент CA возвращает новый сертификат (при успешном выполнении запроса) в сообщении kup33, синтаксически идентичном сообщению CertRepMessage.

7. Согласование версий

В этом разделе определено согласование версий между клиентом и серверов в целях поддержки ранних протоколов.

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

Если сервер получает сообщение поддерживаемой им версии, версия отклика должна совпадать с версией полученного сообщения. Если сервер получает сообщение, номер версии которого выше или ниже номера версии, поддерживаемого сервером, он должен возвратить сообщение ErrorMsg с установленным битом unsupportedVersion (в поле failureInfo структуры pKIStatusInfo). Если версия полученного сообщения выше старшей версии, поддерживаемой сервером, указываемая в сообщении об ошибке версия должна совпадать с максимальной версией, поддерживаемой сервером; если версия полученного сообщения ниже минимальной версии, поддерживаемой сервером, в сообщении об ошибке должна указываться минимальная версия из числа поддерживаемых сервером.

Если клиент получает сообщение ErrorMsgContent с установленным битом unsupportedVersion и поддерживаемым клиентом номером версии, он может повторить запрос с использованием указанной в сообщении об ошибке версии.

7.1. Поддержка реализаций RFC 2510

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

7.1.1. Взаимодействие клиентов с серверами RFC 2510

Если после передачи сообщения cmp2000 клиент получает ErrorMsgContent с версией cmp1999, он должен прервать текущую транзакцию. После этого клиент может повторить попытку с использованием сообщений версии cmp1999.

Если клиент получает не связанное с ошибкой сообщение PKIMessage версии cmp1999, он может принять решение о продолжении транзакции (если она еще не закончена) с использованием семантики RFC 2510. Если клиент не хочет продолжать, а транзакция еще не завершена, клиент должен прервать транзакцию и передать сообщение ErrorMsgContent с версией cmp1999.

7.1.2. Сервер, получаюзий сообщения cmp1999

Если сервер получает сообщение версии cmp1999, он может вернуться к поведению в стиле RFC 2510 и отвечать сообщениями версии cmp1999. Если сервер не пожелает снижать используемую версию, он должен возвратить сообщение ErrorMsgContent, как описано выше в параграфе 7.

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

8.1. Подтверждение владения ключом дешифровки

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

8.2. Подтверждение владения путем раскрытия секретного ключа

Отметим также, что раскрытие секретного ключа агенту CA/RA, как способ подтверждения владения, может приводить к возникновению угроз (в зависимости от того, насколько можно доверять CA/RA в плане корректного обслуживания такой информации). Разработчикам рекомендуется:

соблюдать осторожность при выборе и использовании этого метода POP;

по возможности получать от пользователей приложения явное подтверждение того, что они доверяют CA/RA иметь копию своего секретного ключа, прежде, чем раскрывать этот ключ.

8.3. Атаки на обмен ключами по методу Diffie-Hellman

В процессе обмена ключами по методу D-H возможна незначительная группа атак, описанных ниже. Враждебный конечный элемент преднамеренно выбирает параметры D-H, позволяющие ему получить секретный ключ D-H (или достаточно большую его часть) для агента CA при операциях архивирования и восстановления ключей. На основе этой информации EE сможет восстановить секретный ключ расшифровки другого конечного элемента (ничего не подозревающего об этом) EE2, в процессе легитимной операции по архивированию ключа EE2 на данном CA. Для предотвращения такой возможности есть два варианта. (1) CA может генерировать свежую пару ключей D-H для использования в качестве протокольной пары ключей шифрования каждому EE, с которым он взаимодействует. (2) CA может использовать протокол валидации ключей (не описан в этом документе) для каждого запрашивающего конечного элемента, чтобы гарантировать защищенность протокольной пары ключей шифрования EE от таких атак. Вариант(1) явно проще (не требует дополнительного протокольного обмена от какой-либо из сторон) и, следоваетльно, рекомендован к применению.

9. Согласование с IANA

Типы сообщений PKI общего назначения различаются по идентификаторам объекта (OID). Значения OID для PKI General Message (сообщения общего назначения), определенные в этом документе, были выделены из сегмента, переданного IANA рабочей группе PKIX.

Упоминаемые в документе криптографические алгоритмы различаются по идентификаторам объектов (OID). Значения OID для криптографических алгоритмов были выделены из нескольких сегментов, принадлежащих разным организациям, включая RSA Security, Entrust Technologies, IANA и IETF.

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

От IANA не требуется выполнения каких-либо действий или внесения изменений в связи с данной спецификацией.

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

[X509] International Organization for Standardization and International Telecommunications Union, «Information technology — Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks», ISO Standard 9594-8:2001, ITU-T Recommendation X.50934, March 2000.

[MvOV97] Menezes, A., van Oorschot, P. and S. Vanstone, «Handbook of Applied Cryptography», CRC Press ISBN 0-8493-8523-7, 1996.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

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

[RFC2202] Cheng, P. and R. Glenn, «Test Cases for HMAC-MD5 and HMAC-SHA-1», RFC 2202, September 1997.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC2482] Whistler, K. and G. Adams, «Language Tagging in Unicode Plain Text», RFC 2482, January 1999.

[CRMF] Schaad, J., «Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)», RFC 4211, September 2005.

[RFC3066] Alvestrand, H., «Tags for the Identification of Languages», BCP 47, RFC 3066, January 2001.

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

[CMPtrans] Kapoor, A., Tschalar, R. and T. Kause, «Internet X.509 Public Key Infrastructure — Transport Protocols for CMP», Work in Progress. 2004.

[PKCS7] RSA Laboratories, «The Public-Key Cryptography Standards — Cryptographic Message Syntax Standard. Version 1.5», PKCS 7, November 1993.

[PKCS10] Nystrom, M., and B. Kaliski, «The Public-Key Cryptography Standards — Certification Request Syntax Standard, Version 1.7», RFC 2986, May 2000.

[PKCS11] RSA Laboratories, «The Public-Key Cryptography Standards — Cryptographic Token Interface Standard. Version 2.10», PKCS 11, December 1999.

[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, «Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted», RFC 1847, October 1995.

[RFC2559] Boeyen, S., Howes, T. and P. Richard, «Internet X.509 Public Key Infrastructure Operational Protocols — LDAPv2», RFC 2559, April 1999.

[RFC2585] Housley, R. and P. Hoffman, «Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP», RFC 2585, May 1999.

[FIPS-180] National Institute of Standards and Technology, «Secure Hash Standard», FIPS PUB 180-1, May 1994.

[FIPS-186] National Institute of Standards and Technology, «Digital Signature Standard», FIPS PUB 186, May 1994.

[ANSI-X9.42] American National Standards Institute, «Public Key Cryptography for The Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography», ANSI X9.42, February 2000.

Приложение A. Основания для присутствия RA

Причины присутствия агентов RA можно разделить на технические и организационные. Технические причины перечислены ниже.

  • используются аппаратные маркеры, но не все конечные элементы имеют оборудование для их инициализации — оборудование RA может обеспечивать требуемую функциональность (это может быть также связано с политикой);
  • некоторые конечные элементы не могут публиковать сертификаты — агент RA может делать это за них;
  • RA имеет возможность эмиттировать подписанные запросы на отзыв от имени связанных с ним конечных элементов, тогда как конечные элементы могут не иметь такой возможности (если ключевая пара полностью потеряна).Ниже перечислены некоторые причины организационного характера, обуславливающие присутствие RA.
  • Концентрация функциональности в оборудовании RA может оказаться более экономичной по сравнению с реализацией тех же функций на всех конечных элементах (особенно при использовании специального оборудования для работы с аппаратными маркерами);
  • организация RA может снизить число требуемых для работы агентов CA, что в некоторых случаях весьма желательно;
  • RA может обеспечивать больше возможностей сопоставления людей с их «электронными» именами, особенно для случаев физической удаленности CA от конечного элемента;
  • для многих приложений уже имеются те или иные административные структуры, поэтому кандидата на роль RA найти достаточно просто (для CA это может оказаться сложнее).

Приложение B. Использование пароля для отзыва

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

В некоторых средах используется механизм «отзыва по паролю» (revocation passphrase), в котором значение с достаточной энтропией (т. е., достаточно длинный пароль) совместно используется конечным илементом и CA/RA (и неизвестно другим) до запроса на отзыв — это значение может служить для заверения запроса на отзыв.

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

  • OID и значение, заданное в параграфе 5.3.19.9, могут в любое время быть переданы в сообщении GenMsg или в поле generalInfo заголовка PKIHeader любого сообщения PKIMessage (в частности, значение EncryptedValue может быть передано в сообщении certConf, которое подтверждает приемлемость сертификатов, запрошенных в сообщении с запросом инициализации или сертификата). Они передают пароль на отзыв, выбранный элементом (т. е., зашифрованные байты поля encValue) соответствующему агенту CA/RA; более того, передача выполняется с использованием соответствующих параметров защиты конфиденциальности (поскольку пароль шифруется с помощью ключа protocolEncryptionKey агента CA/RA).
  • Если агент CA/RA получает пароль для отзыва (OID и значение, заданное в параграфе 5.3.19.9) в сообщении GenMsg, он должен создать и передать сообщение GenRep, которое включает OID (без значения), как указано в параграфе 5.3.19.9. Если агент CA/RA получает пароль на отзыв в поле generalInfo заголовка PKIHeader в любом сообщении PKIMessage, он должен включить OID (без значения) в поле generalInfo заголовка PKIHeader соответствующего отклика PKIMessage. Если агент CA/RA не может возвратить требуемый отклик по той или иной причине, он должен передать сообщение об ошибке со статусом «отказ» (rejection), в которое может включить поле failInfo с описанием причины.
  • Поле valueHint в EncryptedValue может содержать идентификатор ключа (выбирается элементом вместе с паролем), который будет помогать при последующем поиске корректного пароля (например, при создании запроса на отзыв элементом или при получении такого запроса агентом CA/RA).
  • Сообщение с запросом на отзыв защищается с помощью PasswordBasedMAC, где пароль на отзыв служит ключом. В тех случаях, когда это приемлемо, поле senderKID в заголовке PKIHeader может содержать значение, переданное ранее в valueHint.

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

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

Приложение C. Разъяснение поведения для запросов

При наличии расхождений с [CRMF], которые будут вызывать проблемы интерпретации или интероперабельности, [CRMF] следует трактовать, как нормативный документ.

Приведенные ниже определения заимствованы из [CRMF]. Эти определения включены для того, чтобы разъяснить поведенческие характеристики запросов; в остальных случаях синтаксис и семантика идентичны [CRMF].

   CertRequest ::= SEQUENCE {
       certReqId     INTEGER,
       certTemplate  CertTemplate,
       controls      Controls OPTIONAL }

   -- Если certTemplate представляет собой пустую последовательность SEQUENCE (т. е., все
   -- поля опущены), поле controls МОЖЕТ содержать значение id-regCtrl-altCertTemplate,
   -- задающее шаблон для сертификата, отличного от сертификата открытого ключа X.509v3
   -- И наоборот, если значение certTemplate не пусто (т. е., заполнено хотя бы одно поле),
   -- в поле НЕДОПУСТИМО включать значение id-regCtrl-altCertTemplate. Новый элемент 
   -- управления определяется следующим образом:

   id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
   AltCertTemplate ::= AttributeTypeAndValue

   POPOSigningKey ::= SEQUENCE {
       poposkInput           [0] POPOSigningKeyInput OPTIONAL,
       algorithmIdentifier   AlgorithmIdentifier,
       signature             BIT STRING }

   -- **********
   -- * Для данной спецификации комментарий ASN.1, данный в [CRMF], относится не только к     
   -- * certTemplate, но и к altCertTemplate.
   -- **********
   -- * Подпись (с использованием algorithmIdentifier) является DER-представлением 
   -- * poposkInput (т. е., «значением» OCTETsof для POPOSigningKeyInput DER). 
   -- * Примечание: Если CertReqMsgcertReq certTemplate (или altCertTemplate) содержит
   -- * значения subject и publicKey, поле poposkInput ДОЛЖНО быть опущено и подпись ДОЛЖНА
   -- * рассчитываться для DER-представления значения CertReqMsg certReq (или 
   -- * AltCertTemplate). Если certTemplate/altCertTemplate не содержит значений субъекта
   -- * и открытого ключа (т. е., содержится одно из этих значений или отсутствуют оба),
   -- * поле poposkInput ДОЛЖНО присутствовать и ДОЛЖНО быть подписано.
   -- **********

   POPOPrivKey ::= CHOICE {
       thisMessage       [0] BIT STRING,

   -- **********
   -- * Тип thisMessage в [CRMF] указан, как строка битов (BIT STRING); следует использовать
   -- * тип EncryptedValue (в соответствии с параграфом 5.2.2. Зашифрованные значения данной
   -- * спецификации). Следовательно, данный документ разъясняет поведение, указывая, что
   -- * содержимое поля thisMessage ДОЛЖНО кодироваться, как  EncryptedValue и после этого
   -- * «преобразовываться» в BIT STRING. Такой подход обеспечивает требуемую транспортировку 
   -- * и защиту секретного ключа и совместимость на уровне битового представления с
   -- * требованиями [CRMF].
   -- **********

       subsequentMessage [1] SubsequentMessage,
       dhMAC             [2] BIT STRING }

 

Приложение D. Профили управляющих сообщений PKI (обязательные)

В этом приложении дано подробное описание профилей для тех сообщений PKIMessage, которые должны поддерживаться соответствующими спецификации реализациями (см. раздел 6).

Представлены профили для сообщений PKIMessage, используемых в операциях управления PKI:

  • начальная регистрация/сертфикация;
  • схема с базовой идентификацией;
  • запрос сертификата;
  • обновление ключа.

D.1. Общие правила интерпретации профилей

  1. Когда поле типа OPTIONAL или DEFAULT не упомянуто в индивидуальном профиле, его не следует включать в соответствующее сообщение (иначе получатель может отбросить такое сообщение, как синтаксически некорректное). Обязательные не указываются, если они имеют обычное значение (например, в данной версии спецификации pvno всегда принимает значение 2).
  2. Когда структуры встречаются более, чем в одном сообщении, они по мере возможности указываются в профиле раздельно.
  3. Идентификаторы алгоритмов из структуры PKIMessage указываются в профиле раздельно.
  4. «Специальное» отличительное имя X.500 DN называется NULL-DN — это обозначает DN с последовательностью SEQUENCE OF RelativeDistinguishedNames нулевого размера (ее DER-представление — 3000 в шестнадцатеричном формате).
  5. В тех случаях, когда для поля требуется GeneralName, а подходящее значение недоступно (например, конечный элемент создает запрос до того, как станет известно его имя), для GeneralName используется значение X.500 NULL-DN (т. е., поле Name в CHOICE содержит NULL-DN). Этот специальный случай называют NULL-GeneralName.
  6. Когда в профиле не указано значение GeneralName, в соответствующем поле сообщения PKIMessage указывается NULL-GeneralName. В частности, это относится к полю sender заголовка PKIHeader некоторых сообщений.
  7. Там где может возникать неоднозначность в результате именования полей, в именах профилей используется нотация с точками (например, certTemplate.subject означает поле subject в поле с именем certTemplate).
  8. Там, где SEQUENCE OF type является частью сообщения, используется нотация на основе массива с нулевой базой для описания полей в последовательности SEQUENCE OF (например, crm[0].certReq.certTemplate.subject указывает на субполе первого CertReqMsg, содержащегося в запросе).
  9. Весь обмен сообщениями PKI, описанными в параграфах D.4 — D.6, требует передачи сообщений certConf элементом-инициатором и сообщений PKIConfirm с отвечающей стороны. Сообщения PKIConfirm не включены в некоторые профили, поскольку тело этих сообщений имеет значение NULL, а содержимое заголовка не включает контекста. Для protectionAlg могут использоваться любые идентифицированные способы (например, MAC на базе пароля, если известен разделяемый секрет, или цифровая подпись).

D.2. Алгоритм использования профиля

В приведенной ниже таблице даны определения алгоритмов, используемых в протоколах управления PKI. Таблица включает 4 колонки:

Имя: идентификатор, используемый для профилей сообщений;

Применение: описание цели и места использования алгоритма;

Обязательные: значения AlgorithmIdentifier, которые должны поддерживаться реализациями;

Прочие: дополнения к обязательным алгоритмам AlgorithmIdentifier.

Имя Применение Обязательные Прочие
MSG_SIG_ALG Защита сообщений PKI с использованием подписи DSA/SHA-1 RSA/MD5, ECDSA, …
MSG_MAC_ALG Защита сообщений PKI с использованием MAC PasswordBasedMac HMAC, X9.9…
SYM_PENC_ALG Симметричное шифрование секретного ключа конечного элемента в тех случаях, когда ключ симметричного шифрования распространяется автономно 3-DES (3-key-EDE, режим CBC) AES, RC5, CAST-128…
PROT_ENC_ALG Для шифрования (симметричных ключей, используемых для шифрования) секретных ключей, передаваемых в сообщениях PKIMessage, применяется асимметричный алгоритм D-H RSA, ECDH, …
PROT_SYM_ALG Для шифрования битов секретного ключа (ключи этого типа шифруются с помощью PROT_ENC_ALG) используется симметричный алгоритм 3-DES (3-key-EDE, режим CBC) AES, RC5, CAST-128…

Идентификаторы и спецификации обязательных алгоритмов:

DSA/SHA-1:

AlgId: {1 2 840 10040 4 3};

Стандарт цифровой подписи [FIPS-186]

Размер открытого модуля: 1024 бита.

PasswordBasedMac:

AlgId: {1 2 840 113533 7 66 13} с SHA-1 {1 3 14 3 2 26} в качестве параметра owf и HMAC-SHA1 {1 3 6 1 5 5 8 1 2} в качестве параметра mac;

(данная спецификация) вместе с

Стандарт защищенного хэширования [FIPS-180] и [RFC2104]

Размер ключа HMAC: 160 битов (т. е., «K» = «H» в параграфе 5.1.3.1. Разделяемый секрет)

3-DES:

AlgId: {1 2 840 113549 3 7}; (используется в BSAFE алгоритма RSA и в S/MIME).

D-H:

AlgId: {1 2 840 10046 2 1};

[ANSI-X9.42]

Размер открытого модуля: 1024 бита.

 DomainParameters ::= SEQUENCE {
    p       INTEGER, -- нечетный первичный, p=jq +1
    g       INTEGER, -- генератор, g^q = 1 mod p
    q       INTEGER, -- первичный множитель p-1
    j       INTEGER OPTIONAL, -- сомножитель, j>=2
    validationParms  ValidationParms OPTIONAL
 }
 ValidationParms ::= SEQUENCE {
    seed          BIT STRING, -- «затравка» для генерации первичного
    pGenCounter   INTEGER     -- верификация параметра
 }

D.3. Подтверждение владения профилем

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

Поле Значение Комментарий
algorithmIdentifier MSG_SIG_ALG Для этого подтверждения разрешена только защита цифровой подписью.
signature присутствует Биты, рассчитанные с использованием MSG_SIG_ALG.

Для подтверждения владения секретным ключом дешифровки, соответствующим открытому ключу шифрования, для которого был запрошен сертификат, этот профиль не используется — взамен его применяется поле CertHash в сообщении certConf.

Не каждый агент CA/RA будет выполнять POP (для ключа подписи, ключа дешифровки или ключа согласования ключей) с использованием протокола запроса сертификатов по основному каналу PKIX-CMP (способ выполнения POP может, в конечном счете, определятьмя политикой для любого заданного CA в его публикуемом Policy OID36 и Certification Practice Statement37). Однако данная спецификация требует, чтобы агенты CA/RA выполняли POP (тем или иным способом), как часть процесса сертификации. Все конечные элементы должны быть готовы обеспечить POP (т. е., эти компоненты протокола PKIX-CMP должны поддерживаться).

D.4. Начальная регистрация/сертификация (базовая схема)

(Инициализированный) конечный элемент запрашивает (первый) сертификат у агента CA. Когда CA отвечает сообщением, содержащим сертификат, конечный элемент отвечает подтверждением приема сертификата. Агент CA возвращает сообщение PKIConfirm конечному элементу и завершает транзакцию. Все сообщения заверяются.

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

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

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

Предпосылки:

  1. конечный элемент может заверять подпись CA на основе автономных механизмов;
  2. конечный элемент и CA совместно используют симметричный ключ MACing.

Поток сообщений:

этапа

Конечный элемент

PKI

1

Форматирование ir

2

->

ir

->

3

Обработка ir

4

Форматирование ip

5

<-

ip

<-

6

Обработка ip

7

Форматирование certConf

8

->

certConf

->

9

Обработка certConf

10

Форматирование PKIConf

11

<-

PKIConf

<-

12

ОбработкаPKIConf

Для этого профиля вводится требование о том, что конечный элемент должен включать все (т. е., один или два) CertReqMsg в одно сообщение PKIMessage, а PKI (CA) должен генерировать одно сообщение PKIMessage, содержащее полный отклик (т. е., включающее опциональную вторую пару ключей, если та была запрошена и централизованная генерация ключей поддерживается). Для простоты спецификация также требует, что это сообщение должно быть окончательным (т. е., не использовалось значение статуса waiting ожидание).

Конечный элемент осуществляет также взаимодействие с агентом CA/RA по отдельному каналу (автономно). Эта транзакция создает разделяемый секрет, ссылочный номер referenceNumber и, опционально, отличительное имя, используемые для имен отправителя и субъекта в шаблоне сертификата. Рекомендуется использовать разделяемый секрет размером не менее 12 символов.

Запрос инициализации — ir

   Поле                 Значение
   recipient            имя CA
     -- имя агента CA, у которого будет запрашиваться эмиссия сертификата
   protectionAlg        MSG_MAC_ALG
     -- для этого запроса разрешена только защита MAC на основе ключа начальной идентификации
   senderKID            referenceNum
     -- ссылочный номер, который ранее агент CA выдал для конечного элемента (вместе с ключом
     -- MACing)
   transactionID        присутствует
     -- зависящее от реализации значение, не имеющее смысла для конечного элемента.
     -- [если идентификатор уже используется на CA, агент CA ДОЛЖЕН генерировать сообщение об
     -- отказе]
   senderNonce          присутствует
     -- 128 (pseudo-)random bits
   freeText             любое корректное значение
   body                 ir (CertReqMessages)
                        допускается только 1 или 2 сообщения CertReqMsg
     -- если требуется большее число сертификатов, запросы ДОЛЖНЫ помещаться в отдельные 
     -- сообщения PKIMessages

   CertReqMsg           присутствует одно или два
     -- более подробное описание приведено ниже
     -- crm[0] обозначает первое (которое ДОЛЖНО присутствовать), а crm[1] — второе (которое
     -- является ОПЦИОНАЛЬНЫМ и служит для запроса централизованно генерируемого ключа)

   crm[0].certReq.      Фиксированное значение 0
      certReqId
     -- индекс шаблона в сообщении
   crm[0].certReq       присутствует
      certTemplate
     -- ДОЛЖНО включать значение открытого ключа субъекта, других ограничений нет
   crm[0].pop...        присутствует опционально, если открытый ключ
      POPOSigningKey    из crm[0].certReq.certTemplate является ключом подписи
     -- в этом обмене МОЖЕТ потребоваться подтверждение владения (см. Приложение D.3)
   crm[0].certReq.      присутствует опционально
      controls.archiveOptions
     -- конечный элемент МОЖЕТ запросить архивирование лакально сгенерированного секретного
     -- ключа
   crm[0].certReq.      присутствует опционально
      controls.publicationInfo
     -- конечный элемент МОЖЕТ запросить публикацию полученного в результате сертификата
   crm[1].certReq       Фиксированное значение 1
      certReqId
     -- индекс шаблона в сообщении
   crm[1].certReq       присутствует
      certTemplate
      -- НЕДОПУСТИМО включение реальных битов открытого ключа, других ограничений нет 
      -- (например, имена не обязаны совпадать с именами в crm[0]).
      -- Отметим, что поле subjectPublicKeyInfo МОЖЕТ присутствовать и содержать
      -- AlgorithmIdentifier, за которым следует  BIT STRING нулевого размера для
      -- subjectPublicKey, если желательно информировать CA/RA об алгоритме и параметрах, 
      -- которые являются предпочтительными для генерируемой пары ключей.
   crm[1].certReq.      присутствует [идентификатор объекта ДОЛЖЕН быть PROT_ENC_ALG]
      controls.protocolEncrKey
     -- усли централизованная генерация ключей поддерживается данным агентом CA, этот
     -- краткосрочный асимметричный ключ шифрования (генерируемый конечным элементом) будет
     -- использоваться CA для шифрования (симметричного ключа, используемого для шифрования)
     -- секретного ключа, генерируемого CA от имени конечного элемента
   crm[1].certReq.      присутствует опционально
      controls.archiveOptions
   crm[1].certReq.      присутствует опционально
      controls.publicationInfo
   protection           присутствует
     -- bits calculated using MSG_MAC_ALG

Отклик при инициализации — ip

   Поле                 Значение
   sender               имя CA
     -- имя агента CA, создавшего сообщение
   messageTime          присутствует
     -- время создания сообщения агентом CA
   protectionAlg        MS_MAC_ALG
     -- для этого отклика разрешена только MAC-защита
   senderKID            referenceNum
     -- ссылочный номер, который CA ранее эмиттировал для конечного элемента (вместе с ключом
     -- MACing)
   transactionID        присутствует
     -- значение из соответствующего сообщения ir
   senderNonce          присутствует
     -- 128 (псевдо-)случайных битов
   recipNonce           присутствует
     -- значение из senderNonce соответствующего сообщения ir
   freeText             любое допустимое значение
   body                 ip (CertRepMessage)
                        содержит в точности один отклик для каждого запроса

     -- PKI (CA) отвечает на один или два запроса подобающим образом. crc[0] обозначает
     -- первое (присутствует всегда); crc[1] - второе (присутствует лишь в случаях, когда
     -- сообщение ir содержит два запроса и CA поддерживает централизованную генерацию ключей)
   crc[0].              фиксированное значение 0
      certReqId
     -- ДОЛЖНО содержать отклик на первый запрос в соответствующем сообщении ir

   crc[0].status.       присутствует, разрешены позитивные значения
      status               "accepted", "grantedWithMods"
                        и негативное значение "rejection"
   crc[0].status.       присутствует тогда и только тогда, когда 
      failInfo          crc[0].status.status = "rejection"
   crc[0].              присутствует  тогда и только тогда, когда
      certifiedKeyPair  crc[0].status.status имеет значение "accepted" или "grantedWithMods"
   certificate          присутствует, если открытый ключ конечного элемента не является ключом
                        шифрования и POP не выполняется в этом обмене сообщениями
   encryptedCert        присутствует  тогда и только тогда, когда открытый ключ является
                        ключом шифрования и POP осуществляется в этом обмене сообщениями
   publicationInfo      присутствует опционально

     -- показывает, где будет публиковаться сертификат (включается по усмотрению CA)

   crc[1].              иксированное значение 1
      certReqId
     -- ДОЛЖНО содержать отклик на второй запрос в соответствующем сообщении ir
   crc[1].status.       присутствует, разрешены позитивные значения 
      status               "accepted", "grantedWithMods"
                        и негативное значение "rejection"
   crc[1].status.       присутствует тогда и только тогда, когда
      failInfo          crc[0].status.status = "rejection"
   crc[1].              присутствует  тогда и только тогда, когда
      certifiedKeyPair  crc[0].status.status имеет значение "accepted" или "grantedWithMods"
   certificate          присутствует

   privateKey           присутствует
     -- см. Приложение Приложение C. Разъяснение поведения для запросов
   publicationInfo      присутствует опционально
     -- показывает, где будет публиковаться сертификат (включается по усмотрению CA)

   protection           присутствует
     -- биты, рассчитанные с использованием MSG_MAC_ALG
   extraCerts           присутствует опционально
     -- агент CA МОЖЕТ обеспечить конечному элементу дополнительные сертификаты

Подтверждение сертификата — certConf

   Поле                 Значение
   sender               присутствует
     -- как для сообщений ir
   recipient            имя CA
     -- имя агента CA, у которого запрошен выпуск сертификата
   transactionID        присутствует
     -- значение из соответствующих сообщений ir и ip
   senderNonce          присутствует
     -- 128 (псевдо-)случайных битов
   recipNonce           присутствует
     -- значение из senderNonce соответствующего сообщения ip
   protectionAlg        MSG_MAC_ALG
     -- для этого сообщения разрешена только MAC-защита. Значение MAC создается на базе 
     -- начального ключа идентификации, совместно используемого EE и CA.

   senderKID            referenceNum
     -- ссылочный номер, который CA ранее эмиттировал для конечного элемента (вместе с ключом
     -- MACing)

   body                 certConf
     -- см. параграф 5.3.18. Содержимое подтверждения сертификата, где описано содержимое 
     -- полей certConf. Примечание: две структуры CertStatus требуются в случаях, когда  
     -- передаются оба сертификата (для шифрования и подписи).

   protection           присутствует
     -- биты, рассчитанные с использованием MSG_MAC_ALG

Подтверждение — PKIConf

   Поле                 Значение
   sender               присутствует
     -- как для сообщений ip
   recipient            присутствует
     -- имя отправителя из certConf
   transactionID        присутствует
     -- значение из сообщения certConf
   senderNonce          присутствует
     -- 128 (псевдо-)случайных битов
   recipNonce           присутствует
     -- значение из поля senderNonce сообщения certConf
   protectionAlg        MSG_MAC_ALG
     -- для этого сообщения разрешена только MAC-защита
   senderKID            referenceNum
   body                 PKIConf
   protection           присутствует
     -- биты, рассчитанные с использованием MSG_MAC_ALG

 

D.5. Запрос сертификата

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

Профиль для этого обмена идентичен профилю, описанному в Приложении D.4 с некоторыми исключениями:

  • следует включать имя отправителя;
  • должно поддерживаться поле protectionAlg в MSG_SIG_ALG (может поддерживаться также MSG_MAC_ALG) для сообщений запроса, отклика certConfirm и PKIConfirm;
  • поля senderKID и recipKID присутствуют только в тех случаях, когда они требуются для верификации сообщения;
  • тело сообщения представляет собой cr или cp;
  • тело сообщения может содержать одну или две структуры CertReqMsg — любая из них может использоваться для запроса сертификации локально сгенерированного открытого ключа или сгенерированного централизованно открытого ключа (т. е., требование по размещению этих структур, приведенное в Приложении D.4, в данном случае снимается);
  • биты защиты рассчитываются в соответствии с полем protectionAlg.

D.6. Запрос обновления ключа

(Инициализированный) конечный элемент запрашивает сертификат у агента CA (для обновления ключевой пары и/или соответствующего сертификата, которым он уже владеет). already possesses). Когда CA отвечает сообщением, содержащим сертификат, конечный элемент отвечает на это сообщение подтверждением сертификата. CA тогда передает сообщение PKIConfirm для завершения транзакции. Все сообщения заверяются.

Профиль для этого обмена идентичен профилю, описанному в Приложении D.4 с некоторыми исключениями:

  1. следует включать имя отправителя;
  2. должно поддерживаться поле protectionAlg в MSG_SIG_ALG (может поддерживаться также MSG_MAC_ALG) для сообщений запроса, отклика certConfirm и PKIConfirm;
  3. поля senderKID и recipKID присутствуют только в тех случаях, когда они требуются для верификации сообщения;
  4. тело представляет собой kur или kup;
  5. тело сообщения может содержать одну или две структуры CertReqMsg — любая из них может использоваться для запроса сертификации локально сгенерированного открытого ключа или сгенерированного централизованно открытого ключа (т. е., требование по размещению этих структур, приведенное в Приложении D.4, в данном случае снимается);
  6. биты защиты рассчитываются в соответствии с полем protectionAlg;
  7. следует использовать regCtrl OldCertId (пока для отправителя и получателя с помощью не задаваемых этой спецификацией мер не становится очевидной ненужность этого).

Приложение E. Профили управляющих сообщений PKI (опция).

В этом приложении приведены подробные профили для тех сообщений PKIMessage, которые могут поддерживаться реализациями (в дополнение к тем сообщениям, которые должны поддерживаться — см. раздел 6 и Приложение D).

Представлены профили сообщений PKIMessage для следующих операций управления PKI:

  • обновление ключа корневого CA;
  • информационный запрос/отклик;
  • запрос/отклик при кросс-сертификации (1-сторонний)
  • инициализация по основному каналу с использованием внешнего сертификата тождественности.

Будущие версии этого документа могут быть расширены путем добавления профилей для перечисленных ниже операций (вместе с другими нужными операциями):

  • запрос отзыва;
  • публикация сертификата;
  • публикация CRL.

E.1. Общие правила интерпретации профилей

Идентично Приложению D.1.

E.2. Алгоритм использования профиля

Идентично Приложению D.2.

E.3. Самоподписанные сертификаты

Профиль показывает, как структура Certificate может быть «самоподписана». Такие структуры используются для распространения открытых ключей агентов CA. Процесс может выполняться одним из трех способов (см. параграф 4.4, где дано описание этих структур.

Тип Назначение

newWithNew

Корректный «самоподписанный» сертификат; содержащийся открытый ключ должен быть пригоден для верификации подписи (хотя при этом обеспечивается только проверка целостность и не проверяется идентификация).

oldWithNew

Прежний открытый ключ корневого CA с новым секретным ключом.

newWithOld

Новый открытый ключ корневого CA с прежним секретным ключом.

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

E.4. Обновление ключа корневого CA

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

Сообщение ckuann

Поле Значение Комментарий

sender

имя CA имя CA

body

ckuann(CAKeyUpdAnnContent)

oldWithNew

присутствует см. Приложение E.3

newWithOld

присутствует см. Приложение E.3

newWithNew

присутствует см. Приложение E.3

extraCerts

присутствует опционально

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

E.5. Информационный запрос/отклик PKI

Конечный элемент передает сообщение общего назначения PKI, запрашивая детальную инфомацию, которая может потребоваться для последующих операций управления PKI. Агент RA/CA дает отклик общего назначения. Если отклик генерирует агент RA, это будет просто пересылка соответствующего сообщения, полученного ранее от CA, с возможным добавлением сертификатов в поля extraCerts сообщения PKIMessage. Подтверждения от конечного элемента не требуется.

Поток сообщений

Этап Конечный элемент

PKI

1

Форматирование genm

2

->

genm

->

3

Обработка genm

4

Создание genp

5

<-

genp

<-

6

Обработка genp

genM

   Поле                Значение
   recipient           имя CA
     -- имя агента CA, как оно указано в расширениях issuerAltName или полях 
     -- issuer сертификатов
   protectionAlg       MSG_MAC_ALG или MSG_SIG_ALG
     -- любой заверенный алгоритм защиты
   SenderKID           присутствует при необходимости
     -- должно присутствовать, если требуется для верификации защиты сообщения
   freeText            любое корректное значение
   body                genr (GenReqContent)
   GenMsgContent       пустая SEQUENCE
     -- вся запрошенная информация, имеющая отношение к делу
   protection           присутствует
     -- биты, рассчитанные с использованием MSG_MAC_ALG или MSG_SIG_ALG

genP

   Поле                 Значение
   sender               имя CA
     -- имя агента CA, создавшего сообщение
   protectionAlg        MSG_MAC_ALG или MSG_SIG_ALG
     -- любой заверенный алгоритм защиты
   senderKID            присутствует при необходимости
     -- должно присутствовать, если требуется для верификации защиты сообщения
   body                 genp (GenRepContent)
   CAProtEncCert        присутствует (идентификатор объекта одного из PROT_ENC_ALG), с  
                        соответствующим значением
     -- будет использоваться, если конечному элементу необходимо зашифровать информацию для 
     -- CA (например, секретный ключ для восстановления)

   SignKeyPairTypes     присутствует с соответствующим значением
     -- набор идентификаторов алгоритмов защиты, которые данный CA будет сертифицировать
     -- для открытых ключей субъекта
   EncKeyPairTypes      присутствует с соответствующим значением
     -- набор алгоритмов шифрования/согласования ключей, которые данный CA будет 
     -- сертифицировать для открытых ключей субъекта
   PreferredSymmAlg     присутствует (идентификатор объекта одного из PROT_ENC_ALG), с  
                        соответствующим значением
     -- симметричный алгоритм, который данный CA предполагает использовать в последующих 
     -- сообщениях PKI (для шифрования)
   CAKeyUpdateInfo      опционально присутствует с соответствующим значением
     -- CA МОЖЕТ предоставлять информацию о соответствуюзей паре ключей корневого CA
     -- с использованием этого поля (отметим, что это не предполагает того, что отвечающий 
     -- агент CA является корневым CA, о котором идет речь)
   CurrentCRL           опционально присутствует с соответствующим значением
     -- CA МОЖЕТ предоставлять копию полного списка CRL (т. е., максимально заполненую)
   protection           присутствует
     -- биты, рассчитанные с использованием MSG_MAC_ALG или MSG_SIG_ALG
   extraCerts           опционально присутствует
     -- может использоваться для передачи некоторых сертификатов конечному элементу; 
     -- RA МОЖЕТ добавить сюда свой сертификат.

 

E.6. Запрос/отклик кросс-сертификации (односторонний)

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

Предпосылки.

  1. отвечающий CA может проверить источник запроса (возможно, это потребует «автономных» мер) перед обработкой запроса;
  2. отвечающий CA может заверить подлинность источника запроса (возможно, это потребует «автономных» мер) перед обработкой запроса.

Использование подтверждения сертификата и подтверждения соответствующего сервера определяется полем generalInfo в заголовке PKIHeader (параграф 5.1.1). Приведенный профиль не требует каких-либо подтверждений.

Поток сообщений

Этап Запрашивающий CA

Отвечающий CA

1

Форматирование ccr

2

->

ccr

->

3

Обработка ccr

4

Создание ccp

5

<-

ccp

<-

6

Обработка ccp

ccr

   Поле                 Значение
   sender               имя запрашивающего CA
     -- имя агента CA, создавшего сообщение
   recipient            имя отвечающего CA
     -- имя агента CA, у которого запрашивается создание кросс-сертификата
   messageTime          время создания сообщения
     -- текущее время запрашивающего CA
   protectionAlg        MSG_SIG_ALG
     -- для этого запроса допустима только защита цифровой подписью
   senderKID            присутствует при необходимости
     -- должно присутствовать, если требуется верификация защиты сообщения
   recipKID             присутствует при необходимости
     -- должно присутствовать, если требуется верификация защиты сообщения
   transactionID        присутствует
     -- зависящее от реализации значение, понятное запрашивающему CA (если такой идентификатор 
     -- уже используется на отвечающем CA, им ДОЛЖНО генерироваться сообщение об отказе)
   senderNonce          присутствует
     -- 128 (псевдо-)случайных битов
   freeText             любое допустимое значение
   body                 ccr (CertReqMessages)
                        разрешается только одно поле CertReqMsg
     -- если требуется множество кросс-сертификатов, они ДОЛЖНЫ помещаться в отдельные 
     -- сообщения PKIMessage
   certTemplate         присутствует
     -- Детали приведены ниже
   version              v1 или v3
     -- НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ v3
   signingAlg           присутствует
     -- запрашивающий CA должен знать заранее с каким алгоритмом он хочет получить
     -- подпись в сертификате

   subject              присутствует
     -- может принимать значение NULL-DN только при наличии расширения subjectAltNames 
   validity             присутствует
     -- ДОЛЖНО быть задано полностью (т. е., оба поля должны присутствовать)
   issuer               присутствует
     -- может принимать значение NULL-DN только при наличии расширения issuerAltNames 
   publicKey            присутствует
     -- ключ, который будет сертифицирован (должен быть ключом алгоритма подписи)
   extensions           присутствует опционально
     -- запрашивающий CA должен предложить значения для всех расширений, которые требуются 
     -- в кросс-сертификате
   POPOSigningKey       присутствует
     -- см. Приложение D.3. Подтверждение владения профилем
   protection           присутствует
     -- биты, рассчитанные с использованием MSG_SIG_ALG
   extraCerts           присутствует опционально
     -- МОЖЕТ содержать любые дополнительные сертификаты, которые запрашивающая сторона
     -- желает включить

ccp

   Поле                  Значение
   sender                имя отвечающего CA
     -- имя агента CA, создавшего сообщение
   recipient             имя запрашивающего CA
     -- имя агента CA, который запросил выпуск сертификата
   messageTime           время создания сообщения
     -- текущее время отвечающего CA
   protectionAlg         MSG_SIG_ALG
     -- для защиты этого сообщения может использоваться только цифровая подпись
   senderKID             присутствует при необходимости
     -- должно присутствовать, если требуется верификация защиты сообщения
   recipKID              присутствует при необходимости
   transactionID         присутствует
     -- значение из соответствующего сообщения ccr
   senderNonce           присутствует
     -- 128 (псевдо-)случайных битов
   recipNonce            присутствует
   -- senderNonce из соответствующего сообщения ccr
   freeText              любое допустимое значение
   body                  ccp (CertRepMessage)
                         допустимо только одно поле CertResponse
     -- если требуется множество кросс-сертификатов, они ДОЛЖНЫ помещаться в отдельные 
     -- сообщения PKIMessage
   response              присутствует
   status                присутствует

   PKIStatusInfo.status  присутствует
     -- если PKIStatusInfo.status имеет значение accepted или grantedWithMods, поле
     -- certifiedKeyPair ДОЛЖНО присутствовать, а failInfo ДОЛЖНО отсутствовать

   failInfo              присутствует в зависимости от PKIStatusInfo.status
     -- если PKIStatusInfo.status = rejection, поле certifiedKeyPair ДОЛЖНО отсутствовать, 
     -- а failInfo ДОЛЖНО присутствовать и содержать подходящие установки битов

   certifiedKeyPair      присутствует в зависимости от PKIStatusInfo.status
   certificate           присутствует в зависимости от  certifiedKeyPair

     -- содержимое актуального сертификата должно проверяться запрашивающим CA до публикации
   protection            присутствует
     -- биты, рссчитанные с использованием MSG_SIG_ALG
   extraCerts            присутствует опционально
     -- МОЖЕТ содержать любые дополнительные сертификаты, которые отвечающая сторона
     -- желает включить

 

E.7. Инициализация по основному каналу с использованием внешнего сертификата тождественности

(Неинициализированный) конечный элемент желает инициализировать себя в PKI с использованием агента CA-1. Он использует для заверения существующий сертификат, эмиттированный агентом CA-X. Между CA-1 и CA-X уже должны быть установлены доверительные отношения, поэтому CA-1 может подтвердить сертификат тождественности EE, подписанный агентом CA-X. Кроме того, требуется организация неких механизмов в среде персональной защиты (PSE38) элемента EE, позволяющие заверить и проверить сообщения PKIMessage, подписанные CA-1 (например, PSE может включать сертификат, выпущенный для открытого ключа CA-1, подписанный другим CA, которому EE доверяет на основе автономных механизмов заверения).

EE передает инициализационный запрос для начала транзакции. Когда CA-1 ответит сообщением, содержащим новый сертификат, конечный элемент ответит на это сообщение подтверждением сертификата. CA-1 ответит сообщением PKIConfirm для завершения транзакции. Все сообщения подписываются (сообщения EE подписываются с использованием секретного ключа, который соответствует открытому ключу внешнего сертификата тождественности; сообщения CA-1 подписываются с использованием секретного ключа, соответствующего открытому ключу в сертификате, который связан с доверенной привязкой в среде PSE конечного элемента).

Профиль для этого обмена идентичен профилю, описанному в приложении D.4, с некоторыми исключениями:

  • EE и CA-1 не имеют разделяемого симметричного ключа MACing (т. е., здесь не организуется разделяемая с помощью автономных мер между элементами секретная информация);
  • имя отправителя в ir должно присутствовать (и совпадать с именем субъекта во внешнем сертификате тождественности);
  • поле protectionAlg MSG_SIG_ALG должно использоваться во всех сообщениях;
  • внешний сертификат тождественности должен передаваться в поле extraCerts сообщения ir;
  • senderKID и recipKID не используются;
  • телом сообщения является ir или ip;
  • биты защиты рассчитываются в соответствии с полем protectionAlg.

Приложение F. Компилируемые определения ASN.1

PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) 
           pkix(7) id-mod(0) id-mod-cmp2000(16)}

     DEFINITIONS EXPLICIT TAGS ::=

     BEGIN
     -- Экспортировать все --
     IMPORTS
         Certificate, CertificateList, Extensions, AlgorithmIdentifier,
         UTF8String -- если требуется; в противном случае «закомментировать»
                FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1)
                security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}

         GeneralName, KeyIdentifier
                FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 
                security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}

         CertTemplate, PKIPublicationInfo, EncryptedValue, CertId, CertReqMessages
                FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1)
                security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)}

         -- см. также характеристики поведения CRMF в Приложении C к данной спецификации

         CertificationRequest
                FROM PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549)
                              pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)}

         -- (задано в RFC 2986 с синтаксисом 1993 ASN.1 и ЯВНЫМИ тегами); в дополнение к этому
         -- разработчики могут напрямую включить в этот модуль синтаксис [PKCS10]
         ;

   -- остальная часть модуля содержит локально определяемые идентификаторы OID и конструкции

      CMPCertificate ::= CHOICE {
         x509v3PKCert        Certificate
      }
   -- Этот синтаксис, будучи совместимым на уровне битового представления сигналов в проводе, 
   -- с определением Certificate в стандарте X.509, обеспечивает возможность введения новых
   -- типов сертификатов (таких, как сертификаты атрибутов X.509, сертификаты WAP WTLS и др.) 
   -- в рамках данного протокола управления сертификатами, не требуя ничего для поддержки
   -- такой общности. Реализации, которые не видят необходимости поддерживать сертификаты 
   -- других типов, МОГУТ, при желании, «закомментировать» приведенную выше структуру и 
   -- «раскомментировать» приведенную ниже структуру до компиляции модуля ASN.1 (отметим, 
   -- что это не оказывает влияния на интероперабельность с реализациями, не делающими так)

   -- CMPCertificate ::= Certificate

      PKIMessage ::= SEQUENCE {
         header           PKIHeader,
         body             PKIBody,
         protection   [0] PKIProtection OPTIONAL,
         extraCerts   [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate    OPTIONAL
     }

     PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage

     PKIHeader ::= SEQUENCE {
         pvno                INTEGER     { cmp1999(1), cmp2000(2) },
         sender              GeneralName,
         -- идентифицирует отправителя
         recipient           GeneralName,
         -- идентифицирует адресата
         messageTime     [0] GeneralizedTime         OPTIONAL,
         -- время создания сообщения (используется, когда отправитель предполагает, что
         -- транспорт будет «подходящим» (т. е., значение будет иметь смысл и при получении)
         protectionAlg   [1] AlgorithmIdentifier     OPTIONAL,
         -- алгоритм, используемый для расчета битов защиты
         senderKID       [2] KeyIdentifier           OPTIONAL,
         recipKID        [3] KeyIdentifier           OPTIONAL,
         -- идентификация конкретных ключей, используемых для защиты
         transactionID   [4] OCTET STRING            OPTIONAL,
         -- идентифицирует транзакцию (т. е., будет совпадать в соответствующих сообщениях 
         -- запроса, отклика, certConf и PKIConf
         senderNonce     [5] OCTET STRING            OPTIONAL,
         recipNonce      [6] OCTET STRING            OPTIONAL,
         -- временные маркеры, служащие для защиты от повторного использования; значение 
         -- senderNonce помещается создателем сообщения, а recipNonce является маркером,
         -- ранее помещенным в соответствующее сообщение адресатом данного сообщения
         freeText        [7] PKIFreeText             OPTIONAL,
         -- может использоваться для передачи контекстно-зависимых инструкций
         -- (предназначено для чтения людьми)
         generalInfo     [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue     OPTIONAL
         -- может использоваться для передачи контекстно-зависимой информации
         -- (предназначено для чтения людьми)
     }

     PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
         -- текст представляется в форме UTF-8 String [RFC3629] (каждая строка UTF8String
         -- МОЖЕТ включать язык тегов [RFC3066] для индикации языка содержащегося в
         -- поле текста; побробное описание содержится в [RFC2482])

     PKIBody ::= CHOICE {       -- специфичные для сообщения элементы тела сообщения
         ir       [0]  CertReqMessages,        --Запрос инициализации
         ip       [1]  CertRepMessage,         --Отклик при инициализации
         cr       [2]  CertReqMessages,        --Запрос сертификации
         cp       [3]  CertRepMessage,         --Отклик при сертификации
         p10cr    [4]  CertificationRequest,   --импортировано из [PKCS10]
         popdecc  [5]  POPODecKeyChallContent, --Вызов pop
         popdecr  [6]  POPODecKeyRespContent,  --Отклик при pop
         kur      [7]  CertReqMessages,        --Запрос на обновление ключа
         kup      [8]  CertRepMessage,         --Отклик при обновлении ключа
         krr      [9]  CertReqMessages,        --Запрос на восстановление ключа
         krp      [10] KeyRecRepContent,       --Отклик при восстановлении ключа
         rr       [11] RevReqContent,          --Запрос на отзыв
         rp       [12] RevRepContent,          --Отклик при отзыве
         ccr      [13] CertReqMessages,        --Запрос кросс-сертификации
         ccp      [14] CertRepMessage,         --Отклик при кросс-сертификации
         ckuann   [15] CAKeyUpdAnnContent,     --Анонс обновления ключа CA
         cann     [16] CertAnnContent,         --Анонс сертификата
         rann     [17] RevAnnContent,          --Анонс отзыва
         crlann   [18] CRLAnnContent,          --Анонс CRL
         pkiconf  [19] PKIConfirmContent,      --Подтверждение
         nested   [20] NestedMessageContent,   --Вложенное сообщение
         genm     [21] GenMsgContent,          --Сообщение общего назначения
         genp     [22] GenRepContent,          --Отклик общего назначения
         error    [23] ErrorMsgContent,        --Сообщение об ошибке
         certConf [24] CertConfirmContent,     --Подтверждение сертификата
         pollReq  [25] PollReqContent,         --Запрос опроса
         pollRep  [26] PollRepContent          --Отклик при опросе
     }

     PKIProtection ::= BIT STRING

     ProtectedPart ::= SEQUENCE {
         header    PKIHeader,
         body      PKIBody
     }

     id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
     PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         -- Примечание: реализация МОЖЕТ ограничивать допустимый размер строки для снижения 
         -- риска атак на службы
         owf                 AlgorithmIdentifier,
         -- AlgId для необратимой функции (рекомендуется SHA-1)
         iterationCount      INTEGER,
         -- число итераций OWF
         -- Примечание: реализация МОЖЕТ ограничивать допустимый размер строки для снижения 
         -- риска атак на службы
         mac                 AlgorithmIdentifier
         -- MAC AlgId (например, DES-MAC, Triple-DES-MAC [PKCS11] или HMAC [RFC2104, RFC2202])
     }   

     id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
     DHBMParameter ::= SEQUENCE {
         owf                 AlgorithmIdentifier,
         -- для необратимой функции (рекомендуется SHA-1)
         mac                 AlgorithmIdentifier
         -- MAC AlgId (например, DES-MAC, Triple-DES-MAC [PKCS11] или HMAC [RFC2104, RFC2202])
     }   

     NestedMessageContent ::= PKIMessages

     PKIStatus ::= INTEGER {
         accepted               (0),
         -- получено именно то, что запрашивалось
         grantedWithMods        (1),
         -- получено что-то похожее на запрошенную информацию; запрашивающая сторона 
         -- принимает на себя ответственность за нахождение различий
         rejection              (2),
         -- не получено, дополнительная информация в сообщении
         waiting                (3),
         -- тело запроса еще не обработано, отклик будет позднее (примечание: при корректной
         -- обработке такого отклика МОГУТ использоваться опросные сообщения «запрос-отклик», 
         -- описанные в параграфе 5.3.22; другим вариантом является опрос нижележащего 
         -- транспортного уровня, который МОЖЕТ оказаться полезным)
         revocationWarning      (4),
         -- сообщение содержит предупреждение о неминуемости отзыва
         revocationNotification (5),
         -- уведомление о произошедшем отзыве
         keyUpdateWarning       (6)
         -- обновление уже выполнено для oldCertId, заданного в CertReqMsg
     }

     PKIFailureInfo ::= BIT STRING {
     -- Поскольку возможно множество причин отказов, в будущем могут быть добавлены новые коды
         badAlg              (0),
         -- нераспознанный или неподдерживаемый идентификатор алгоритма
         badMessageCheck     (1),
         -- отказ при проверке целостности (например, подпись не соответствует)
         badRequest          (2),
         -- транзакция не разрешена или не поддерживается
         badTime             (3),
         -- значение messageTime отличается от системного времени более, чем позволяет 
         -- локальная политика
         badCertId           (4),
         -- не найдено сертификата, соответствующего представленным критериям
         badDataFormat       (5),
         -- данные представлены в некорректном формате
         wrongAuthority      (6),
         -- агентство, указанное в запросе отличается от создавшего маркер отклика
         incorrectData       (7),
         -- данные запрашивающей стороны некорректны (для нотариальных услуг)
         missingTimeStamp    (8),
         -- временная метка отсутствует, но требуется (политикой)
         badPOP              (9),
         -- отказ при проверке pop
         certRevoked         (10),
            -- сертификат уже отозван
         certConfirmed       (11),
            -- сертификат уже подтвержден
         wrongIntegrity      (12),
            -- некорректный контроль целостности — на базе пароля взамен подписи или наоборот           
         badRecipientNonce   (13),
            -- некорректный временный маркер получателя (значение отуствтует или некорректно)          
         timeNotAvailable    (14),
            -- данные о времени TSA недоступны
         unacceptedPolicy    (15),
            -- запрошенная политика TSA не поддерживается TSA
         unacceptedExtension (16),
            -- запрошенное расширение не поддерживается TSA
         addInfoNotAvailable (17),
            -- запрошенная дополнительная информация непонятна или недоступна
         badSenderNonce      (18),
            -- некорректный временный маркер отправителя (значение отуствтует или некорректно)
         badCertTemplate     (19),
            -- некорректный шаблон сертификата или отсутствует обязательная информация
         signerNotTrusted    (20),
            -- подписавшая сторона неизвестна или не пользуется доверием
         transactionIdInUse  (21),
            -- идентификатор транзакции уже используется
         unsupportedVersion  (22),
            -- версия сообщения не поддерживается
         notAuthorized       (23),
            -- отправитель не уполномочен выполнять предшествующий запрос или действие
         systemUnavail       (24),
         -- запрос не может быть обработан по причине системной недоступности
         systemFailure       (25),
         -- запрос не может быть обработан по причине системно отказа
         duplicateCertReq    (26)
         -- сертификат не может быть выпущен, поскольку уже существует дубликат сертификата
     }

     PKIStatusInfo ::= SEQUENCE {
         status        PKIStatus,
         statusString  PKIFreeText     OPTIONAL,
         failInfo      PKIFailureInfo  OPTIONAL
     }

     OOBCert ::= CMPCertificate

     OOBCertHash ::= SEQUENCE {
         hashAlg     [0] AlgorithmIdentifier     OPTIONAL,
         certId      [1] CertId                  OPTIONAL,
         hashVal         BIT STRING
         -- hashVal рассчитывается для DER-представления самоподписанного сертификата с
         -- идентификатором certID.
     }

     POPODecKeyChallContent ::= SEQUENCE OF Challenge
     -- Используется один запрос Challenge на запрос сертификации ключа шифрования (в том же 
     -- порядке, как эти запросы указаны в сообщениях CertReqMessage).

     Challenge ::= SEQUENCE {
         owf                 AlgorithmIdentifier  OPTIONAL,
         -- ДОЛЖНО присутствовать в первом Challenge; МОЖЕТ быть опущено в последующих 
         -- Challenge в POPODecKeyChallContent (если опущено, будет использоваться owf из 
         -- непосредственно предшествующего Challenge).

         witness             OCTET STRING,
         -- результат применения необратимой функции (owf) к случайному числу INTEGER, A.  
         -- (отметим, что для каждого Challenge ДОЛЖНЫ использоваться разные значения INTEGER)
         challenge           OCTET STRING
         -- зашифрованное (с использованием открытого ключа, для которого запрашивается
         -- сертификат) значение Rand, где Rand задано, как показано ниже
         --   Rand ::= SEQUENCE {
         --      int      INTEGER,
         --       - случайное значение INTEGER A (см. выше)
         --      sender   GeneralName
         --       - имя отправителя (как в заголовке PKIHeader)
         --   }
     }

     POPODecKeyRespContent ::= SEQUENCE OF INTEGER
     -- Одно значение INTEGER на запрос сертификации ключа шифрования (в том же порядке, 
     -- который используется в сообщениях CertReqMessage). Восстановленное значение INTEGER A 
     -- (см. выше) возвращается отправителю соответствующего Challenge.

     CertRepMessage ::= SEQUENCE {
         caPubs       [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate    OPTIONAL,
         response         SEQUENCE OF CertResponse
     }

     CertResponse ::= SEQUENCE {
         certReqId           INTEGER,
         -- для сопоставления этого отклика с соответствующим запросом (значение -1 
         -- используется в том случае, когда значение certReqId не задано в запросе)

         status              PKIStatusInfo,
         certifiedKeyPair    CertifiedKeyPair    OPTIONAL,
         rspInfo             OCTET STRING        OPTIONAL
         -- аналогично строке id-regInfo-utf8Pairs, определенной для regInfo в CertReqMsg 
         -- [CRMF]
     }

     CertifiedKeyPair ::= SEQUENCE {
         certOrEncCert       CertOrEncCert,
         privateKey      [0] EncryptedValue      OPTIONAL,
         -- см. комментарии по представлению в [CRMF]
         publicationInfo [1] PKIPublicationInfo  OPTIONAL
     }

     CertOrEncCert ::= CHOICE {
         certificate     [0] CMPCertificate,
         encryptedCert   [1] EncryptedValue
     }

     KeyRecRepContent ::= SEQUENCE {
         status                  PKIStatusInfo,
         newSigCert          [0] CMPCertificate OPTIONAL,
         caCerts             [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL,
         keyPairHist         [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair OPTIONAL
     }

     RevReqContent ::= SEQUENCE OF RevDetails

     RevDetails ::= SEQUENCE {
         certDetails         CertTemplate,
         -- позволяет запрашивающему подробно описать сертификат, для которого запрашивается 
         -- отзыв (например, для случаев, когда значение serialNumber недоступно)
         crlEntryDetails     Extensions       OPTIONAL
         -- запрошенные расширения crlEntryExtensions
     }

     RevRepContent ::= SEQUENCE {
         status       SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
         -- в том же порядке, как передано в RevReqContent
         revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId    OPTIONAL,
         -- значения ID для каждого запрошенного отзыва (в том же поряжке, как статус)
         crls     [1] SEQUENCE SIZE (1..MAX) OF CertificateList    OPTIONAL
         -- результирующие списки CRL (может быть несколько)
     }

     CAKeyUpdAnnContent ::= SEQUENCE {
         oldWithNew   CMPCertificate, -- старый открытый ключ, подписанный новым секретным
         newWithOld   CMPCertificate, -- новый открытый ключ, подписанный старым секретным
         newWithNew   CMPCertificate  -- новый открытый ключ, подписанный новым секретным
     }

     CertAnnContent ::= CMPCertificate

     RevAnnContent ::= SEQUENCE {
         status              PKIStatus,
         certId              CertId,
         willBeRevokedAt     GeneralizedTime,
         badSinceDate        GeneralizedTime,
         crlDetails          Extensions  OPTIONAL
         -- дополнительные детали CRL (например, номер, причина, местоположение и т. п.)
     }

     CRLAnnContent ::= SEQUENCE OF CertificateList

     CertConfirmContent ::= SEQUENCE OF CertStatus

     CertStatus ::= SEQUENCE {
        certHash    OCTET STRING,
        -- хэш-сумма для сертификата, вычисленная с использованием того же алгоритма, 
        -- который применяется для создания и проверки сертификата подписи
        certReqId   INTEGER,
        -- для сопоставления данного подтверждения с соответствующим «запросом-откликом»
        statusInfo  PKIStatusInfo OPTIONAL
     }

     PKIConfirmContent ::= NULL

     InfoTypeAndValue ::= SEQUENCE {
         infoType               OBJECT IDENTIFIER,
         infoValue              ANY DEFINED BY infoType  OPTIONAL
     }
     -- Пример содержимого InfoTypeAndValue включает, но не ограничивается приведенным ниже
     -- («раскомментируйте» в этом модуле ASN.1 и используйте подходящее для вашей среды:
     --
     --   id-it-caProtEncCert    OBJECT IDENTIFIER ::= {id-it 1}
     --      CAProtEncCertValue      ::= CMPCertificate
     --   id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2}
     --      SignKeyPairTypesValue   ::= SEQUENCE OF AlgorithmIdentifier
     --   id-it-encKeyPairTypes  OBJECT IDENTIFIER ::= {id-it 3}
     --      EncKeyPairTypesValue    ::= SEQUENCE OF AlgorithmIdentifier
     --   id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4}
     --      PreferredSymmAlgValue   ::= AlgorithmIdentifier
     --   id-it-caKeyUpdateInfo  OBJECT IDENTIFIER ::= {id-it 5}
     --      CAKeyUpdateInfoValue    ::= CAKeyUpdAnnContent
     --   id-it-currentCRL       OBJECT IDENTIFIER ::= {id-it 6}
     --      CurrentCRLValue         ::= CertificateList
     --   id-it-unsupportedOIDs  OBJECT IDENTIFIER ::= {id-it 7}
     --      UnsupportedOIDsValue    ::= SEQUENCE OF OBJECT IDENTIFIER
     --   id-it-keyPairParamReq  OBJECT IDENTIFIER ::= {id-it 10}
     --      KeyPairParamReqValue    ::= OBJECT IDENTIFIER
     --   id-it-keyPairParamRep  OBJECT IDENTIFIER ::= {id-it 11}
     --      KeyPairParamRepValue    ::= AlgorithmIdentifer
     --   id-it-revPassphrase    OBJECT IDENTIFIER ::= {id-it 12}
     --      RevPassphraseValue      ::= EncryptedValue
     --   id-it-implicitConfirm  OBJECT IDENTIFIER ::= {id-it 13}
     --      ImplicitConfirmValue    ::= NULL
     --   id-it-confirmWaitTime  OBJECT IDENTIFIER ::= {id-it 14}
     --      ConfirmWaitTimeValue    ::= GeneralizedTime
     --   id-it-origPKIMessage   OBJECT IDENTIFIER ::= {id-it 15}
     --      OrigPKIMessageValue     ::= PKIMessages
     --   id-it-suppLangTags     OBJECT IDENTIFIER ::= {id-it 16}
     --      SuppLangTagsValue       ::= SEQUENCE OF UTF8String
     --
     -- где
     --   id-pkix OBJECT IDENTIFIER ::= {
     --      iso(1) identified-organization(3)
     --      dod(6) internet(1) security(5) mechanisms(5) pkix(7)}
     -- и
     --   id-it   OBJECT IDENTIFIER ::= {id-pkix 4}
     --
     -- Эта конструкция МОЖЕТ использоваться также для определения новых запросов и откликов  
     -- PKIX CMP или сообщения общего назначения (например, анонсов) в соответствии с 
     -- будущими потребностями конкретных сред.

     GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
     -- Может передаваться элементом EE, RA или CA (в зависимости от содержимого). 
     -- ОПЦИОНАЛЬНЫЙ параметр infoValue в InfoTypeAndValue обычно был опущен в приведенных
     -- выше примерах. Получатель волен игнорировать все включенные идентификаторы объектов,
     -- которые он не распознал. При передаче от EE к CA пустой набор показывает, что CA 
     -- может передать любую (всю) информацию, которую он захочет.

     GenRepContent ::= SEQUENCE OF InfoTypeAndValue
     -- Получатель МОЖЕТ игнорировать все нераспознанные значения OID.

     ErrorMsgContent ::= SEQUENCE {
         pKIStatusInfo          PKIStatusInfo,
         errorCode              INTEGER           OPTIONAL,
         -- определяемые реализацией коды ошибок
         errorDetails           PKIFreeText       OPTIONAL
         -- определяемая реализацией информация об ошибке
     }

     PollReqContent ::= SEQUENCE OF SEQUENCE {
         certReqId              INTEGER
     }

     PollRepContent ::= SEQUENCE OF SEQUENCE {
         certReqId              INTEGER,
         checkAfter             INTEGER,  -- время в секундах
         reason                 PKIFreeText OPTIONAL
     }

     END — завершение модуля CMP

Приложение G. Благодарности

Авторы с благодарностью отмечают вклад членов рабочей группы IETF PKIX и почтовой конференции ICSA CA-talk (созданной для обсуждения вопросов интероперабельности CMP). Усилия этих людей позволили уточнить и сделать более удобной данную спецификацию. Tomi Kause благодарит Vesa Suontama и Toni Tammisalo за их обзор и комментарии.

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

Carlisle Adams

University of Ottawa

800 King Edward Avenue

P.O.Box 450, Station A

Ottawa, Ontario K1N 6N5

CA

Phone: (613) 562-5800 ext. 2345

Fax: (613) 562-5664

EMail: cadams@site.uottawa.ca

Stephen Farrell

Trinity College Dublin

Distributed Systems Group

Computer Science Department

Dublin

IE

Phone: +353-1-608-2945

EMail: stephen.farrell@cs.tcd.ie

Tomi Kause

SSH Communications Security Corp

Valimotie 17

Helsinki 00380

FI

Phone: +358 20 500 7415

EMail: toka@ssh.com

Tero Mononen

SafeNet, Inc.

Fredrikinkatu 47

Helsinki 00100

FI

Phone: +358 20 500 7814

EMail: tmononen@safenet-inc.com


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

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

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Certificate Management Protocol.

2Public Key Infrastructure.

3Certification Authority.

4Certificate Management Protocol.

5Public Key Infrastructure.

6End entity.

7Personal Security Environment.

8Root CA.

9Subordinate CA.

10Registration Authority.

11Certificate Revocation List.

12Denial-of-service attack.

13Отметим, что при компрометации ключа CA для всех элементов домена данного агента CA должна быть выполнена повторная инициализация.

14Certificate Management Protocol — протокол управления сертификатами.

15Key chain file.

16Рассмотрение таких протоколов выходит за пределы данной спецификации.

17Initial Authentication Key.

18Proof-of-Possession.

19Distinguished Name.

20Diffie-Hellman.

21Replay attack — атака с повторным использованием переданных ранее сообщений.

22Message Authentication Code.

23Challenge-response.

24Прямой метод обычно используется в средах, где агент RA верифицирует POP и после этого запрашивает сертификат у CA от имени конечного элемента. В таком сценарии CA доверяет RA в плане корректности проверки POP перед запросом агентом RA сертификата для конечного элемента.

25Key agreement key — ключ согласования ключей.

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

27Signing key.

28Encryption key.

29Cross-certification request.

30Cross-certification response.

31Certification request — запрос сертификации.

32Key update request — запрос на обновление ключей.

33Key update response — отклик на запрос обновления ключей.

34Этот стандарт на русском языке доступен по ссылке. Прим. перев.

36Идентификатор политики.

37Заявление о практике сертификации.

38Personal Security Environment.




RFC 4188 Definitions of Managed Objects for Bridges

Network Working Group                                    K. Norseth, Ed.
Request for Comments: 4188                            L-3 Communications
Obsoletes: 1493                                             E. Bell, Ed.
Category: Standards Track                            3Com Europe Limited
                                                          September 2005

Определения управляемых объектов для мостов

Definitions of Managed Objects for Bridges

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

Документ определяет часть MIB1 для использования с протоколами сетевого управления в сетях TCP/IP. В частности, определены объекты для управления мостами MAC на основе стандарта IEEE 802.1D-1998 между сегментами локальных сетей (ЛВС или LAN). Обеспечивается поддержка прозрачных мостов, а также применимость этих объектов к мостам, соединенным подсетями, которые на являются сегментами ЛВС.

Модуль MIB, представленный в этом документе, является трансляцией в синтаксис SMIv2 модуля BRIDGE-MIB, определенного в RFC 1493.

Этот документ заменяет RFC 1493.

Оглавление

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

1. Стандартная схема управления Internet

Подробный обзор документов, описывающих стандартную схему управления Internet приведен в разделе 7 RFC 3410 [RFC3410].

Доступ к объектам управления осуществляется через виртуальное хранилище, называемое MIB. Для работы с объектами MIB обычно используется простой протокол сетевого управления (SNMP2). Объекты MIB определяются с использованием механизмов, описанных в SMI3. Этот документ задает модуль MIB, соответствующий спецификации SMIv2, которая описана в STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] и STD 58, RFC 2580 [RFC2580].

2. Уровни требований

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

3. Обзор

Базовым устройством многих сетей является мост (Bridge). Такие устройства используются для соединения ЛВС ниже сетевого уровня и часто их называют коммутаторами уровня 2 (layer 2 switch).

Для этих мостов существует два основных режима — transparent (прозрачный) и source route (маршрут, заданный отправителем). Режим прозрачного моста определен в спецификации IEEE 802.1D [IEEE8021D]. Этот документ определяет объекты, требуемые для управления мостом, работающим в прозрачном режиме, а также некоторые объекты для управления всеми типами мостов.

Для совместимости с директивами IAB и имеющимся инженерным опытом была предпринята явная попытка максимально упростить этот модуль MIB. Это достигнуто путем применения к объектам приведенных ниже требований.

  1. Начинать с небольшого набора объектов и дополнять его лишь по необходимости.

  2. Каждый объект должен быть важен для настройки или контроля отказов.

  3. Учет текущего использования и полезности.

  4. Ограничение общего числа объектов.

  5. Исключение объектов, которые выводятся из других объектов этого или других модулей MIB.

  6. Сокращение числа критических сессий. Рекомендуется использовать один счетчик на критическую секцию уровня.

3.1 Структура модуля MIB

Объекты в этом модуле MIB организованы в субдеревья, каждое из которых является набором связанных объектов. Общая структура и распределение объектов по субдеревьям показаны ниже. В тех случаях, когда это возможно, указаны также соответствующие объекты управления IEEE 802.1D [IEEE8021D].

Имя в Bridge MIB

Имя в IEEE 802.1D

dot1dBridge
  dot1dBase

    BridgeAddress
Bridge.BridgeAddress
    NumPorts
Bridge.NumberOfPorts
    Type
    PortTable

      Port                       
      IfIndex
      Circuit
BridgePort.PortNumber
      DelayExceededDiscards
  .DiscardTransitDelay
      MtuExceededDiscards
  .DiscardOnError
  dot1dStp
    ProtocolSpecification

    Priority
SpanningTreeProtocol
  .BridgePriority
    TimeSinceTopologyChange
  .TimeSinceTopologyChange
    TopChanges
  .TopologyChangeCount
    DesignatedRoot
  .DesignatedRoot
    RootCost
  .RootCost
    RootPort
  .RootPort
    MaxAge
  .MaxAge
    HelloTime
  .HelloTime
    HoldTime
  .HoldTime
    ForwardDelay
  .ForwardDelay
    BridgeMaxAge
  .BridgeMaxAge
    BridgeHelloTime
  .BridgeHelloTime
    BridgeForwardDelay
  .BridgeForwardDelay
    PortTable

      Port
SpanningTreeProtocolPort
  .PortNumber
      Priority
  .PortPriority
      State                         
      Enable
  .SpanningTreeState
      PathCost
  .PortPathCost
      DesignatedRoot
  .DesignatedRoot
      DesignatedCost
  .DesignatedCost
      DesignatedBridge
  .DesignatedBridge
      DesignatedPort                
      ForwardTransitions
  .DesignatedPort
  dot1dTp

    LearnedEntryDiscards
BridgeFilter.DatabaseSize
  .NumDynamic,NumStatic
    AgingTime                     
    FdbTable
      Address
      Port
      Status
    PortTable
      Port
      MaxInfo
BridgeFilter.AgingTime
      InFrames
BridgePort.FramesReceived
      OutFrames
  .ForwardOutbound
      InDiscards                    
  dot1dStatic
    StaticTable
      Address
      ReceivePort
      AllowedToGoTo
      Status
  .DiscardInbound

Ниже перечислены объекты управления IEEE 802.1D, которые не были включены в BRIDGE-MIB, в указанием причин.

Объект IEEE 802.1D

Причина исключения

Bridge.BridgeName

Совпадает с sysDescr (SNMPv2-MIB).

Bridge.BridgeUpTime

Совпадает с sysUpTime (SNMPv2-MIB).

Bridge.PortAddresses

Совпадает с ifPhysAddress (IF-MIB).

BridgePort.PortName

Совпадает с ifDescr (IF-MIB).

BridgePort.PortType

Совпадает с ifType (IF-MIB).

BridgePort.RoutingType

Выводится из реализованных субдеревьев.

SpanningTreeProtocol

.BridgeIdentifier

Комбинация dot1dStpPriority и dot1dBaseBridgeAddress.

.TopologyChange

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

SpanningTreeProtocolPort

.Uptime

Совпадает с ifLastChange (IF-MIB).

.PortIdentifier

Комбинация dot1dStpPort и dot1dStpPortPriority.

.TopologyChangeAcknowledged

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

.DiscardLackOfBuffers

Избыточно.

Приоритет передачи

.TransmissionPriorityName

Эти объекты не требуются в соответствии с Pics Proforma и не считаются полезными.

.OutboundUserPriority

.OutboundAccessPriority

3.1.1 Субдерево dot1dBase

Это субдерево содержит объекты, применимые для всех типов мостов.

3.1.2 Субдерево dot1dStp

Это субдерево содержит объекты, которые указывают состояние моста применительно к протоколу STP4. Если узел не поддерживает протокол STP, это субдерево не реализуется.

3.1.3 Субдерево dot1dSr

Это субдерево содержит объекты, которые описывают состояние элемента применительно к мосту source route. Это субдерево описано в RFC 1525 [RFC1525] и применимо только к мостам source route.

3.1.4 Субдерево dot1dTp

Это субдерево содержит объекты, которые описывают состояние элемента применительно к прозрачному мосту. Если прозрачный мост не поддерживается, это субдерево не реализуется. Субдерево применимо лишь к прозрачным и мостам и мостам SRT.

3.1.5 Субдерево dot1dStatic

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

3.2 Связи с другими модулями MIB

Как описано выше, некоторые объекты управления IEEE 802.1D не включены в данный модуль MIB, поскольку они перекрываются с другими объектами MIB, которые применимы к мостам, реализующим этот модуль MIB.

3.2.1 Связь с SNMPv2-MIB

Модуль SNMPv2-MIB [RFC3418] определяет объекты, которые в общем случае применимы к управляемым устройствам. Эти объекты применимы к устройству в целом, независимо от того, выполняет ли устройство только функции моста или эти функции являются лишь частью выполняемых устройством задач.

Как разъяснено в параграфе 3.1, полная поддержка управляемых объектов 802.1D требует реализации объектов SNMPv2-MIB sysDescr и sysUpTime. Отметим, что для совместимости с текущим модулем SNMPv2-MIB требуется реализация дополнительных объектов и уведомлений, как указано в RFC 3418 [RFC3418].

3.2.2 Связь с IF-MIB

Модуль IF-MIB [RFC2863] определяет объекты для управления сетевыми интерфейсами. Сетевой интерфейс рассматривается как подключенный к «подсети» (subnetwork). Отметим, что термин «подсеть» в данном случае имеет иное значение, нежели подсеть в смысле схем адресации, используемых в стеке протоколов IP. В этом документе для таких подсетей используется термин «сегмент», независимо от того, является подсеть сегментом Ethernet, кольцом, каналом WAN или виртуальным устройством X.25.

Как разъяснено в параграфе 3.1, полная поддержка управляемых объектов 802.1D требует реализации объектов IF-MIB ifIndex, ifType, ifDescr, ifPhysAddress и ifLastChange. Отметим, что для совместимости с текущим модулем IF-MIB требуется реализация дополнительных объектов и уведомлений, как указано в RFC 2863 [RFC2863].

Неявным в этом модуле BRIDGE-MIB является обозначение портов моста. Каждый порт связывается с одним из интерфейсов в субдереве interfaces и в большинстве случаев каждый порт связан со своим интерфейсом. Однако в некоторых случаях с одним интерфейсом может быть связано множество портов. Примером может служить ситуация, когда несколько портов, связанных взаимно-однозначно с виртуальными устройствами X.25, относятся к одному интерфейсу.

Каждый порт однозначно указывается номером, который не обязательно связан с номером интерфейса, но в простом случае номер порта совпадает с номером соответствующего интерфейса. Номера портов лежат в диапазоне (1..dot1dBaseNumPorts).

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

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

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

   BRIDGE-MIB DEFINITIONS ::= BEGIN

   -- ---------------------------------------------------------- --
   -- MIB для устройств IEEE 802.1D 
   -- ---------------------------------------------------------- --
   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
       Counter32, Integer32, TimeTicks, mib-2
           FROM SNMPv2-SMI
       TEXTUAL-CONVENTION, MacAddress
           FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
           FROM SNMPv2-CONF
       InterfaceIndex FROM IF-MIB
       ;

   dot1dBridge MODULE-IDENTITY
       LAST-UPDATED "200509190000Z"
       ORGANIZATION "IETF Bridge MIB Working Group"
       CONTACT-INFO
           "Email: bridge-mib@ietf.org
                    K.C. Norseth (Editor)
                    L-3 Communications
               Tel: +1 801-594-2809
             Email: kenyon.c.norseth@L-3com.com
            Postal: 640 N. 2200 West.
                    Salt Lake City, Utah 84116-0850
                    Les Bell (Editor)
                    3Com Europe Limited
             Phone: +44 1442 438025
             Email: elbell@ntlworld.com
            Postal: 3Com Centre, Boundary Way
                    Hemel Hempstead
                    Herts.  HP2 7YU
                    UK
            Send comments to <bridge-mib@ietf.org>"
       DESCRIPTION
           "Модуль Bridge MIB для управления устройствами, 
           поддерживающими IEEE 802.1D.

           Copyright (C) The Internet Society (2005). Эта версия данного
           модуля MIB является частью RFC 4188, где авторские права 
           указаны полностью."
       REVISION     "200509190000Z"
       DESCRIPTION
            "Третий выпуск, опубликованный как часть RFC 4188.

            Модуль MIB был преобразован в формат SMIv2. Было
            добавлено заявление о совместимости, а также обновлено
            описание и ссылки.

            Был добавлен объект dot1dStpPortPathCost32 для поддержки
            IEEE 802.1t и разъяснены допустимые значения 
            dot1dStpPriority и dot1dStpPortPriority для мостов,
            поддерживающих IEEE 802.1t или IEEE 802.1w.

            Разъяснена интерпретация dot1dStpTimeSinceTopologyChange
            для мостов, поддерживающих протокол RSTP5."
       REVISION     "199307310000Z"
       DESCRIPTION
            "Второй выпуск, опубликованный в RFC 1493."
       REVISION     "199112310000Z"
       DESCRIPTION
            "Первоначальный выпуск, опубликованный в RFC 1286."
       ::= { mib-2 17 }

   -- ---------------------------------------------------------- --
   -- Текстовые соглашения
   -- ---------------------------------------------------------- --

   BridgeId ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
           "BridgeId в рамках протокола STP однозначно указывает
           мост. Первые 2 октета (в сетевом порядке байтов)
           содержат значение приоритета, а последние 6 октетов -
           MAC-адрес, используемый для однозначного указания моста
           (обычно это численно меньшее значение из MAC-адресов
           всех портов моста)."
       SYNTAX      OCTET STRING (SIZE (8))

   Timeout ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION
           "Таймер протокола STP в сотых долях секунды. Несколько
           объектов в данном модуле MIB представляют значения
           таймеров, используемых протоколом STP. Все эти таймеры
           в данном модуле MIB указывают время в сотых долях секунды.

           Таймеры в STP BPDU указывают время в 1/256 секунды. Отметим
           однако, что 802.1D-1998 задает настраиваемую дискретность
           (не более 1 сек.) для таких таймеров. Для предотвращения
           неоднозначности ниже определен алгоритм преобразования,
           переводящий из одних единиц в другие.
           Для преобразования значений Timeout в единицы 1/256 сек.
           Используется выражение
               b = floor((n * 256) / 100)
           где
               floor   =  целая часть [остаток игнорируется]
               n — значение в 1/100 сек.
               b — значение в 1/256 сек.

           Для преобразования из 1/256 сек. в сотые доли секунды
           используется выражение
               n = ceiling((b * 100) / 256)
           где
               ceiling = целая часть [если остаток равен 0] или
                         целая часть + 1 [исли остаток больше 0]
               n — значение в 1/100 сек.
               b — значение в 1/256 сек.

           Примечание. Важно выполнять арифметические операции в 
           указанном порядке (т. е. сначала умножение, затем деление)."
       SYNTAX      Integer32

   -- ---------------------------------------------------------- --
   -- субдеревья в Bridge MIB
   -- ---------------------------------------------------------- --

   dot1dNotifications  OBJECT IDENTIFIER ::= { dot1dBridge 0 }

   dot1dBase           OBJECT IDENTIFIER ::= { dot1dBridge 1 }
   dot1dStp            OBJECT IDENTIFIER ::= { dot1dBridge 2 }

   dot1dSr             OBJECT IDENTIFIER ::= { dot1dBridge 3 }
   -- документировано в RFC 1525

   dot1dTp             OBJECT IDENTIFIER ::= { dot1dBridge 4 }
   dot1dStatic         OBJECT IDENTIFIER ::= { dot1dBridge 5 }

   -- Субдеревья, используемые расширениями Bridge MIB:
   --      pBridgeMIB  MODULE-IDENTITY   ::= { dot1dBridge 6 }
   --      qBridgeMIB  MODULE-IDENTITY   ::= { dot1dBridge 7 }
   -- Отметим, что от практики регистрации связанных модулей MIB
   -- под dot1dBridge отказались по причине отсутствия надежного
   -- механизма отслеживания таких регистраций.

   dot1dConformance    OBJECT IDENTIFIER ::= { dot1dBridge 8 }

   -- ---------------------------------------------------------- --
   -- субдерево dot1dBase
   -- ---------------------------------------------------------- --
   -- Реализация dot1dBase обязательна для всех мостов
   -- ---------------------------------------------------------- --

   dot1dBaseBridgeAddress OBJECT-TYPE
       SYNTAX      MacAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "MAC-адрес, используемый мостом в тех случаях, когда требуется
           обеспечить однозначность. Рекомендуется использовать для этого
           численно меньшее значение MAC-адреса среди всех портов моста.
           Однако требуется лишь уникальность значения. При конкатенации
           с dot1dStpPriority образуется уникальное значение 
           BridgeIdentifier, используемое в протоколе STP."
       REFERENCE
           "IEEE 802.1D-1998: clauses 14.4.1.1.3 and 7.12.5"
       ::= { dot1dBase 1 }

   dot1dBaseNumPorts OBJECT-TYPE
       SYNTAX      Integer32
       UNITS       "ports"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Число портов, контролируемых данным мостом."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.4.1.1.3"
       ::= { dot1dBase 2 }
   dot1dBaseType OBJECT-TYPE
       SYNTAX      INTEGER {
                       unknown(1),
                       transparent-only(2),
                       sourceroute-only(3),
                       srt(4)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Indicates what type of bridging this bridge can
           perform.  If a bridge is actually performing a
           certain type of bridging, this will be indicated by
           entries in the port table for the given type."
       ::= { dot1dBase 3 }

   -- ---------------------------------------------------------- --
   -- Базовая таблица портов моста
   -- ---------------------------------------------------------- --
   dot1dBasePortTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF Dot1dBasePortEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Таблица с базовой информацией для каждого порта, связанного
           с этим мостом. Включаются прозрачные, source-route и srt-порты."
       ::= { dot1dBase 4 }

   dot1dBasePortEntry OBJECT-TYPE
       SYNTAX      Dot1dBasePortEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Список информации для каждого порта этого моста."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.4.2, 14.6.1"
       INDEX  { dot1dBasePort }
       ::= { dot1dBasePortTable 1 }

   Dot1dBasePortEntry ::=
       SEQUENCE {
           dot1dBasePort
               Integer32,
           dot1dBasePortIfIndex
               InterfaceIndex,
           dot1dBasePortCircuit
               OBJECT IDENTIFIER,
           dot1dBasePortDelayExceededDiscards
               Counter32,
           dot1dBasePortMtuExceededDiscards
               Counter32
       }

   dot1dBasePort OBJECT-TYPE
       SYNTAX      Integer32 (1..65535)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Номер порта, для которого эта запись содержит данные
           управления мостом."
       ::= { dot1dBasePortEntry 1 }

   dot1dBasePortIfIndex OBJECT-TYPE
       SYNTAX      InterfaceIndex
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Значение экземпляра объекта ifIndex, определенного в
           IF-MIB, для соответствующего этому порту интерфейса."
       ::= { dot1dBasePortEntry 2 }

   dot1dBasePortCircuit OBJECT-TYPE
       SYNTAX      OBJECT IDENTIFIER
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Для порта, который (потенциально) имеет такое же значение
           dot1dBasePortIfIndex как у другого порта в том же мосту.
           Этот объект содержит имя экземпляра объекта, уникальное для
           этого порта. Например, в случае когда множество портов,
           взаимно-однозначно соответствует виртуальным устройствам X.25,
           это значение может указывать (например, первый) экземпляр
           объекта, связанного с виртуальным устройством X.25,
           соответствующим этому порту.

           Для порта, имеющего уникальное значение 
           dot1dBasePortIfIndex, этот объект имеет значение { 0 0 }."
       ::= { dot1dBasePortEntry 3 }

   dot1dBasePortDelayExceededDiscards OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Число кадров, отброшенных этим портом по причине избыточной
           задержки при передаче через мост. Счетчик инкрементируется
           прозрачными и source route мостами."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.6.1.1.3"
       ::= { dot1dBasePortEntry 4 }

   dot1dBasePortMtuExceededDiscards OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Число кадров, отброшенных этим портом по причине избыточного
           размера. Счетчик инкрементируется прозрачными и source route
           мостами."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.6.1.1.3"
       ::= { dot1dBasePortEntry 5 }

   -- ---------------------------------------------------------- --
   -- субдерево dot1dStp 
   -- ---------------------------------------------------------- --
   -- Реализация dot1dStp не обязательна. Оно реализуется мостами,
   -- поддерживающими протокол STP
   -- ---------------------------------------------------------- --

   dot1dStpProtocolSpecification OBJECT-TYPE
       SYNTAX      INTEGER {
                       unknown(1),
                       decLb100(2),
                       ieee8021d(3)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Индикация используемой версии протокола STP. Значение decLb100(2)
           указывает протокол DEC LANbridge 100 STP. Реализации IEEE 802.1D
           будут возвращать значение ieee8021d(3). При выпуске в будущем
           новых версий протокола IEEE STP, не совместимых с текущей версией,
           будут определены новые значения."
       ::= { dot1dStp 1 }

   dot1dStpPriority OBJECT-TYPE
       SYNTAX      Integer32 (0..65535)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "Значение разрешенной для записи части Bridge ID (т. е.
           первые 2 октета 8-октетного Bridge ID). Последние 6 
           октетов Bridge ID заданы значением dot1dBaseBridgeAddress.
           На мостах, поддерживающих IEEE 802.1t или IEEE 802.1w,
           разрешены значения от 0 до 61440 с шагом 4096."
       REFERENCE
           "IEEE 802.1D-1998 clause 8.10.2, Table 8-4,
           IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3."
       ::= { dot1dStp 2 }


   dot1dStpTimeSinceTopologyChange OBJECT-TYPE
       SYNTAX      TimeTicks
       UNITS       "centi-seconds"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Время (в сотых долях секунды) с момента последнего
           изменения топологии, обнаруженного мостом.
           Для RSTP с момента, когда таймер tcWhile любого из
           портов этого моста принял ненулевое значение."
       REFERENCE
           "IEEE 802.1D-1998 clause 14.8.1.1.,
           IEEE 802.1w clause 14.8.1.1."
       ::= { dot1dStp 3 }

   dot1dStpTopChanges OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Общее число изменений топологии, обнаруженных этим
           мостом с момента последнего сброса или инициализации
           элемента управления."
       REFERENCE
           "IEEE 802.1D-1998 clause 14.8.1.1."
       ::= { dot1dStp 4 }

   dot1dStpDesignatedRoot OBJECT-TYPE
       SYNTAX      BridgeId
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Идентификатор моста, служащего корнем остовного дерева,
           определенный протоколом STP, выполняемым на этом узле.
           Это значение служит параметром Root Identifier во всех 
           Configuration Bridge PDU, создаваемых этим узлом."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.3.1"
       ::= { dot1dStp 5 }

   dot1dStpRootCost OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Стоимость пути к корню с точки зрения этого моста."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.3.2"
       ::= { dot1dStp 6 }

   dot1dStpRootPort OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Номер порта, который предлагает самый дешевый путь
           от данного моста к корневому мосту."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.3.3"
       ::= { dot1dStp 7 }

   dot1dStpMaxAge OBJECT-TYPE
       SYNTAX      Timeout
       UNITS       "centi-seconds"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Максимальный возраст информации протокола STP, полученной
           из сети на любом порту, по достижении которого данные 
           отбрасываются (в сотых долях секунды). Это значение,
           используемое мостом в данный момент."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.3.4"
       ::= { dot1dStp 8 }

   dot1dStpHelloTime OBJECT-TYPE
       SYNTAX      Timeout
       UNITS       "centi-seconds"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Интервал между передачей Configuration bridge PDU через
           любой порт данного моста, когда он является или пытается 
           стать корнем STP (в сотых долях секунды). Это значение,
           используемое мостом в данный момент."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.3.5"
       ::= { dot1dStp 9 }

   dot1dStpHoldTime OBJECT-TYPE
       SYNTAX      Integer32
       UNITS       "centi-seconds"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Это значение определяет интервал (в сотых долях секунды),
           в течение которого данным узлом должно передаваться не 
           более двух Configuration bridge PDU."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.3.14"
       ::= { dot1dStp 10 }

   dot1dStpForwardDelay OBJECT-TYPE
       SYNTAX      Timeout
       UNITS       "centi-seconds"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Это значение (в сотых долях секунды) задает как быстро
           порт меняет свое состояние STP при переходе в направлении
           к состоянию Forwarding. Значение определяет время
           пребывания порта в каждом из состояний Listening и
           Learning, предшествующих состоянию Forwarding. Это значение 
           используется также в случае обнаружения происходящей смены
           топологии, чтобы «состарить» все динамические записи в 
           базе данных пересылки. 
           [Отметим, что это значение является одним из тех, которые 
           этот мост использует в настоящий момент в отличие от 
           dot1dStpBridgeForwardDelay, с которым этот и все другие мосты
           начинают работу, когда мост становится корневым.]"
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.3.6"
       ::= { dot1dStp 11 }

   dot1dStpBridgeMaxAge OBJECT-TYPE
       SYNTAX      Timeout (600..4000)
       UNITS       "centi-seconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "Значение, которое все мосты используют в качестве MaxAge,
           когда мост работает в качестве корневого. Отметим, что 802.1D-1998
           задает привязку диапазона для этого параметра к значению параметра
           dot1dStpBridgeHelloTime. Дискретность для этого таймера установлена
           стандартом 802.1D-1998 в 1 сек. Агент может возвращать ошибку
           badValue при попытке установить нецелое число секунд."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.3.8"
       ::= { dot1dStp 12 }

   dot1dStpBridgeHelloTime OBJECT-TYPE
       SYNTAX      Timeout (100..1000)
       UNITS       "centi-seconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "Значение, которое все мосты используют в качестве HelloTime, когда
           мост работает в качестве корневого.  Дискретность для этого таймера
           установлена стандартом 802.1D-1998 в 1 сек. Агент  может возвращать
           ошибку badValue при попытке установить нецелое число секунд."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.3.9"
       ::= { dot1dStp 13 }
   dot1dStpBridgeForwardDelay OBJECT-TYPE
       SYNTAX      Timeout (400..3000)
       UNITS       "centi-seconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "Значение, которое все мосты используют в качестве ForwardDelay,
           когда мост работает в качестве корневого. Отметим, что 802.1D-1998
           задает привязку диапазона для этого параметра к значению параметра
           dot1dStpBridgeMaxAge. Дискретность для этого таймера установлена
           стандартом 802.1D-1998 в 1 сек. Агент может возвращать ошибку
           badValue при попытке установить нецелое число секунд."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.3.10"
       ::= { dot1dStp 14 }

   -- ---------------------------------------------------------- --
   -- Таблица портов STP
   -- ---------------------------------------------------------- --

   dot1dStpPortTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF Dot1dStpPortEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Таблица, содержащая специфическую для порта информацию STP."
       ::= { dot1dStp 15 }

   dot1dStpPortEntry OBJECT-TYPE
       SYNTAX      Dot1dStpPortEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Список поддерживаемой каждым портом информации о состоянии
           протокола STP для данного порта."
       INDEX   { dot1dStpPort }
       ::= { dot1dStpPortTable 1 }

   Dot1dStpPortEntry ::=
       SEQUENCE {
           dot1dStpPort
               Integer32,
           dot1dStpPortPriority
               Integer32,
           dot1dStpPortState
               INTEGER,
           dot1dStpPortEnable
               INTEGER,
           dot1dStpPortPathCost
               Integer32,
           dot1dStpPortDesignatedRoot
               BridgeId,
           dot1dStpPortDesignatedCost
               Integer32,
           dot1dStpPortDesignatedBridge
               BridgeId,
           dot1dStpPortDesignatedPort
               OCTET STRING,
           dot1dStpPortForwardTransitions
               Counter32,
           dot1dStpPortPathCost32
               Integer32
       }

   dot1dStpPort OBJECT-TYPE
       SYNTAX      Integer32 (1..65535)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Номер порта, для которого эта запись содержит управляющую
           информацию протокола STP."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.8.2.1.2"
       ::= { dot1dStpPortEntry 1 }

   dot1dStpPortPriority OBJECT-TYPE
       SYNTAX      Integer32 (0..255)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "Значение поля приоритета, содержащегося в первых 2 октетах
           Port ID. Остальные октеты Port ID задаются значением
           dot1dStpPort. Для мостов с поддержкой IEEE 802.1t или
           IEEE 802.1w допустимы значения от 0 до 240 с шагом 16."
       REFERENCE
           "IEEE 802.1D-1998 clause 8.10.2, Table 8-4,
           IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3."
       ::= { dot1dStpPortEntry 2 }

   dot1dStpPortState OBJECT-TYPE
       SYNTAX      INTEGER {
                       disabled(1),
                       blocking(2),
                       listening(3),
                       learning(4),
                       forwarding(5),
                       broken(6)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Текущее состояние порта, определенное приложением STP.
           Это состояние определяет действия порта при получении
           кадра. При обнаружении неработоспособного порта мост
           устанавливает для него состояние broken(6). Для отключенных
           портов (см. dot1dStpPortEnable), имеет значение disabled(1)."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.5.2"
       ::= { dot1dStpPortEntry 3 }

   dot1dStpPortEnable OBJECT-TYPE
       SYNTAX      INTEGER {
                       enabled(1),
                       disabled(2)
                   }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "Статус порта enabled/disabled (включен/выключен)."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.5.2"
       ::= { dot1dStpPortEntry 4 }

   dot1dStpPortPathCost OBJECT-TYPE
       SYNTAX      Integer32 (1..65535)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "Вклад данного порта в стоимость пути к корню STP через
           этот порт. 802.1D-1998 рекомендует по умолчанию использовать 
           значение, обратно пропорциональное скорости подключенной ЛВС.

           Новым реализациям следует поддерживать dot1dStpPortPathCost32.
           Если стоимость пути через порт превосходит  максимальное
           значение для этого объекта, объекту следует возвращать 
           максимальное значение 65535. Если данный объект возвращает 
           максимальное значение, приложению следует попытаться прочитать
           объект dot1dStpPortPathCost32."
       REFERENCE "IEEE 802.1D-1998: clause 8.5.5.3"
           ::= { dot1dStpPortEntry 5 }

   dot1dStpPortDesignatedRoot OBJECT-TYPE
       SYNTAX      BridgeId
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Уникальный идентификатор моста, записанного в качестве Root 
           в Configuration BPDU, передаваемых Designated Bridge для 
           сегмента, к которому порт подключен."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.5.4"
       ::= { dot1dStpPortEntry 6 }
   dot1dStpPortDesignatedCost OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Стоимость пути Designated Port сегмента, подключенного
           к данному порту. Это значение сравнивается с полем
           Root Path Cost в полученных PDU."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.5.5"
       ::= { dot1dStpPortEntry 7 }

   dot1dStpPortDesignatedBridge OBJECT-TYPE
       SYNTAX      BridgeId
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Идентификатор моста, который данный порт считает
           Designated Bridge для своего сегмента."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.5.6"
       ::= { dot1dStpPortEntry 8 }

   dot1dStpPortDesignatedPort OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE (2))
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Идентификатор порта на Designated Bridge 
           для сегмента данного порта."
       REFERENCE
           "IEEE 802.1D-1998: clause 8.5.5.7"
       ::= { dot1dStpPortEntry 9 }

   dot1dStpPortForwardTransitions OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Число переходов данного порта из состояния Learning 
           в состояние Forwarding."
       ::= { dot1dStpPortEntry 10 }

   dot1dStpPortPathCost32 OBJECT-TYPE
       SYNTAX      Integer32 (1..200000000)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "Вклад данного порта в стоимость пути в направлении
           корня STP через этот порт. 802.1D-1998 рекомендует по
           умолчанию использовать значение, обратно 
           пропорциональное скорости подключенной ЛВС.

           Этот объект заменяет dot1dStpPortPathCost для поддержки
           IEEE 802.1t."
       REFERENCE
           "IEEE 802.1t clause 8.10.2, Table 8-5."
       ::= { dot1dStpPortEntry 11 }

   -- ---------------------------------------------------------- --
   -- субдерево dot1dTp 
   -- ---------------------------------------------------------- --
   -- Реализация dot1dTp не обязательна. Субдерево реализуется
   -- мостами, поддерживающими прозрачный режим, и мостами SRT
   -- ---------------------------------------------------------- --

   dot1dTpLearnedEntryDiscards OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Общее число записей Forwarding Database, которые были 
           получены путем обучения, но отброшены по причине нехватки
           места в Forwarding Database. Если значение счетчика растет,
           это показывает регулярное переполнение Forwarding Database
           (негативное влияние на работу сети). Если значение счетчика
           достаточно велико, но не растет, это показывает, что
           проблема переполнения была временной."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.7.1.1.3"
       ::= { dot1dTp 1 }

   dot1dTpAgingTime OBJECT-TYPE
       SYNTAX      Integer32 (10..1000000)
       UNITS       "seconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "Время (в секундах) старения динамически определенной 
           информации о пересылке. 802.1D-1998 рекомендует 
           использовать по умолчанию 300 секунд."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.7.1.1.3"
       ::= { dot1dTp 2 }

   -- ---------------------------------------------------------- --
   --  База данных пересылки для прозрачных мостов
   -- ---------------------------------------------------------- --

   dot1dTpFdbTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF Dot1dTpFdbEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Таблица с информацией об индивидуальных записях, которые
           мост может использовать для пересылки и/или фильтрации.
           Эта информация применяется функциями прозрачного моста
           для определения действий по отнощению к принятому пакету."
       ::= { dot1dTp 3 }

   dot1dTpFdbEntry OBJECT-TYPE
       SYNTAX      Dot1dTpFdbEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Информация о конкретном индивидуальном MAC-адресе, для
           которого мост имеет информацию о пересылке и/или фильтрации."
       INDEX   { dot1dTpFdbAddress }
       ::= { dot1dTpFdbTable 1 }

   Dot1dTpFdbEntry ::=
       SEQUENCE {
           dot1dTpFdbAddress
               MacAddress,
           dot1dTpFdbPort
               Integer32,
           dot1dTpFdbStatus
               INTEGER
       }

   dot1dTpFdbAddress OBJECT-TYPE
       SYNTAX      MacAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Индивидуальный MAC-адрес, для которого мост имеет
           имеет информацию о пересылке и/или фильтрации."
       REFERENCE
           "IEEE 802.1D-1998: clause 7.9.1, 7.9.2"
       ::= { dot1dTpFdbEntry 1 }

   dot1dTpFdbPort OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "0 или номер порта, на котором был обнаружен кадр с адресом
           отправителя, совпадающим со значением соответствующего
           экземпляра dot1dTpFdbAddress. 0 показывает, что номер порта
           не был определен, но у моста имеется некая информация
           о пересылке/фильтрации для этого адреса (например, в
           dot1dStaticTable). Разработчикам рекомендуется
           назначать этому объекту номер порта, когда он определен,
           даже для адресов, у которых соответствующее значение
           dot1dTpFdbStatus не равно learned(3)."
       ::= { dot1dTpFdbEntry 2 }

   dot1dTpFdbStatus OBJECT-TYPE
       SYNTAX      INTEGER {
                       other(1),
                       invalid(2),
                       learned(3),
                       self(4),
                       mgmt(5)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Статус записи, который может принимать значения:
               other(1) — ни одно из перечисленных ниже. Это включает
                   ситуации, когда некий другой объект MIB (не
                   соответствующий экземпляру dot1dTpFdbPort и не
                   запись в dot1dStaticTable) используется для 
                   определения пересылки кадра, направленного по 
                   адресу из соответствующего dot1dTpFdbAddress.
               invalid(2) — запись больше не пригодна (например,
                   она уже устарела), но еще остается в таблице.
               learned(3) — значение соответствующего экземпляра
                   dot1dTpFdbPort определено и используется.
               self(4) - значение соответствующего экземпляра
                   dot1dTpFdbAddress представляет один из адресов
                   моста. Соответствующий экземпляр dot1dTpFdbPort
                   показывает, какой из портов имеет этот адрес.
               mgmt(5) - значение соответствующего экземпляра
                   dot1dTpFdbAddress является также значением
                   имеющегося экземпляра dot1dStaticAddress."
       ::= { dot1dTpFdbEntry 3 }

   -- ---------------------------------------------------------- --
   --  Таблица портов для прозрачных мостов
   -- ---------------------------------------------------------- --

   dot1dTpPortTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF Dot1dTpPortEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Таблица с информацией для каждого порта, связанного 
           с этим прозрачным мостом."
       ::= { dot1dTp 4 }

   dot1dTpPortEntry OBJECT-TYPE
       SYNTAX      Dot1dTpPortEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Список информации для каждого порта прозрачного моста."
       INDEX   { dot1dTpPort }
       ::= { dot1dTpPortTable 1 }

   Dot1dTpPortEntry ::=
       SEQUENCE {
           dot1dTpPort
               Integer32,
           dot1dTpPortMaxInfo
               Integer32,
           dot1dTpPortInFrames
               Counter32,
           dot1dTpPortOutFrames
               Counter32,
           dot1dTpPortInDiscards
               Counter32
       }

   dot1dTpPort OBJECT-TYPE
       SYNTAX      Integer32 (1..65535)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Номер порта, для которого данная строка содержит
           информацию управления прозрачным мостом."
       ::= { dot1dTpPortEntry 1 }

   -- Было бы хорошо использовать ifMtu в качестве максимального
   -- размера поля INFO, но это невозможно, посокльку ifMtu
   -- определяется как размер, который может использовать
   -- (меж)сетевой уровень, а он может отличаться от уровня MAC
   -- (особенно при использовании нескольких уровней инкапсуляции).

   dot1dTpPortMaxInfo OBJECT-TYPE
       SYNTAX      Integer32
       UNITS       "bytes"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Максимальный размер поля INFO (не MAC), который этот 
           порт будет принимать и передавать."
       ::= { dot1dTpPortEntry 2 }

   dot1dTpPortInFrames OBJECT-TYPE
       SYNTAX      Counter32
       UNITS       "frames"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Число кадров, принятых данным портом из своего сегмента.
           Отметим, что кадры, принятые соответствующим порту
           интерфейсом, учитываются тогда и только тогда, когда они
           относятся к протоколу, обрабатываемому локальной функцией
           моста, включая кадры управления мостом."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.6.1.1.3"
       ::= { dot1dTpPortEntry 3 }

   dot1dTpPortOutFrames OBJECT-TYPE
       SYNTAX      Counter32
       UNITS       "frames"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Число кадров, переданных данным портом в свой сегмент.
           Отметим, что кадры, переданные соответствующим порту 
           интерфейсом, учитываются тогда и только тогда, когда они
           относятся к протоколу, обрабатываемому локальной функцией
           моста, включая кадры управления мостом."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.6.1.1.3"
       ::= { dot1dTpPortEntry 4 }

   dot1dTpPortInDiscards OBJECT-TYPE
       SYNTAX      Counter32
       UNITS       "frames"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Число полученных корректных кадров, которые были отброшены
           (например, отфильтрованы) процессом пересылки."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.6.1.1.3"
       ::= { dot1dTpPortEntry 5 }

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

   dot1dStaticTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF Dot1dStaticEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Таблица, содержащая данные фильтрации, настроенной в
           мосту (локальной или сетевой) системой управления, и 
           задающая набор портов, в которые разрешено пересылать
           кадры из определенных портов, направленные заданным 
           адресатам. Нулевое значение в качестве номера порта в
           этой таблице, из которого приняты кадры для заданного 
           получателя, служит для указания всех портов, которые не 
           имеют специальной записи в этой таблице для данного
           адресата. Записи действуют для индивидуальных, групповых
           и широковещательных адресов."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.7.2"
       ::= { dot1dStatic 1 }

   dot1dStaticEntry OBJECT-TYPE
       SYNTAX      Dot1dStaticEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Данные фильтрации, заданные в мосту (локальной или
           сетевой) системой управления, которые указывают набор
           портов, куда разрешено пересылать кадры, принятые из
           заданного порта и направленные по указанному адресу."
       REFERENCE
           "IEEE 802.1D-1998: clause 14.7.2"
       INDEX   { dot1dStaticAddress, dot1dStaticReceivePort }
       ::= { dot1dStaticTable 1 }

   Dot1dStaticEntry ::=
       SEQUENCE {
           dot1dStaticAddress       MacAddress,
           dot1dStaticReceivePort   Integer32,
           dot1dStaticAllowedToGoTo OCTET STRING,
           dot1dStaticStatus        INTEGER
       }

   dot1dStaticAddress OBJECT-TYPE
       SYNTAX      MacAddress
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "MAC-адрес получателя  в кадре, к которому относится
           данная запись фильтра. Адрес может быть групповым,
           широковещательным или индивидуальным."
       REFERENCE
           "IEEE 802.1D-1998: clause 7.9.1, 7.9.2"
       ::= { dot1dStaticEntry 1 }

   dot1dStaticReceivePort OBJECT-TYPE
       SYNTAX      Integer32 (0..65535)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "0 или номер порта, из которого должен быть принят кадр,
           чтобы к нему применялась данная запись фильтра. Нулевое 
           значение указывает все порты моста, для которых нет 
           других применимых записей."
       ::= { dot1dStaticEntry 2 }

   dot1dStaticAllowedToGoTo OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE (0..512))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Набор портов, в которые разрешено пересылать кадры,
           принятые из заданного порта и направленные по указанному
           MAC-адресу. Каждый октет значения этого объекта задает
           набор из 8 портов — превому октету соответствуют порты 
           1 — 8, второму 9 — 16 и т. д. В каждом октете старший бит 
           представляет порт с меньшим номером, младший — с большим.
           Таким образом, каждый порт моста представлен одним битом
           в значении этого объекта. Установленный бит (1) говорит
           о включении порта в число разрешенных, сброшенный (0)
           исключает пересылку в порт. Отметим, что значение для порта
           из которого принят кадр не принимается во внимание. По
           умолчанию значением этого объекта является строка
           установленных (1) битов соответствующего размера.

           Значение этого поля может выходить за пределы требуемого 
           минимума максимального размера сообщения для 
           некоторых видов транспорта SNMP (484 байтов для UDP, см.
           параграф 3.2 в RFC 3417). Машины SNMP на мостах с 
           большим числом портов должны поддерживать подходящий
           максимальный размер сообщений."
       ::= { dot1dStaticEntry 3 }

   dot1dStaticStatus OBJECT-TYPE
       SYNTAX      INTEGER {
                       other(1),
                       invalid(2),
                       permanent(3),
                       deleteOnReset(4),
                       deleteOnTimeout(5)
                   }
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Объект показывает статус записи. По умолчанию permanent(3).
               other(1) — запись используется в настоящее время, но 
                   условия, при которых она будет сохраняться,
                   отличаются от перечисленных ниже значений.
               invalid(2) — запись этого значения в объект удалит
                   соответствующий элемент.
               permanent(3) - запись используется в настоящее время и
                   сохраниться после следующего сброса (перезапуска) моста.
               deleteOnReset(4) - запись используется в настоящее время и
                   будет сохраняться до сброса (перезапуска) моста.
               deleteOnTimeout(5) - запись используется в настоящее время и
                   будет сохраняться, пока не устареет.
       ::= { dot1dStaticEntry 4 }

   -- ---------------------------------------------------------- --
   -- Уведомления, используемые мостами
   -- ---------------------------------------------------------- --
   -- Уведомления для протокола STP
   -- ---------------------------------------------------------- --

   newRoot NOTIFICATION-TYPE
       -- OBJECTS     { }
       STATUS      current
       DESCRIPTION
           "Уведомление (trap) newRoot указывает, что передающий агент
           стал новым корнем STP. Уведомление передается мостом сразу
           после его выбора новым корнем (например, после завершения
           отсчета таймера Topology Change непосредственно после его
           выбора). Реализация этого уведомления не обязательна."
       ::= { dot1dNotifications 1 }

   topologyChange NOTIFICATION-TYPE
       -- OBJECTS     { }
       STATUS      current
       DESCRIPTION
           "Уведомление topologyChange передается мостом, когда любой 
           из его настроенных портов переходит из состояния Learning в
           состояние Forwarding или из состояния Forwarding в состояние
           Blocking. Уведомление не передается, если для того же перехода
           было передано прерывание newRoot. Реализация этого уведомления
           не обязательна."
       ::= { dot1dNotifications 2 }

   -- ---------------------------------------------------------- --
   -- IEEE 802.1D MIB — информация о соответствии
   -- ---------------------------------------------------------- --

   dot1dGroups         OBJECT IDENTIFIER ::= { dot1dConformance 1 }
   dot1dCompliances    OBJECT IDENTIFIER ::= { dot1dConformance 2 }

   -- ---------------------------------------------------------- --
   -- блоки соответствия
   -- ---------------------------------------------------------- --

   -- ---------------------------------------------------------- --
   -- группа dot1dBase
   -- ---------------------------------------------------------- --

   dot1dBaseBridgeGroup OBJECT-GROUP
       OBJECTS {
           dot1dBaseBridgeAddress,
           dot1dBaseNumPorts,
           dot1dBaseType
       }
       STATUS      current
       DESCRIPTION
           "Информация для моста в целом."
       ::= { dot1dGroups 1 }

   dot1dBasePortGroup OBJECT-GROUP
       OBJECTS {
           dot1dBasePort,
           dot1dBasePortIfIndex,
           dot1dBasePortCircuit,
           dot1dBasePortDelayExceededDiscards,
           dot1dBasePortMtuExceededDiscards
       }
       STATUS      current
       DESCRIPTION
           "Информация для каждого порта устройства."
       ::= { dot1dGroups 2 }

   -- ---------------------------------------------------------- --
   -- группа dot1dStp 
   -- ---------------------------------------------------------- --

   dot1dStpBridgeGroup OBJECT-GROUP
       OBJECTS {
           dot1dStpProtocolSpecification,
           dot1dStpPriority,
           dot1dStpTimeSinceTopologyChange,
           dot1dStpTopChanges,
           dot1dStpDesignatedRoot,
           dot1dStpRootCost,
           dot1dStpRootPort,
           dot1dStpMaxAge,
           dot1dStpHelloTime,
           dot1dStpHoldTime,
           dot1dStpForwardDelay,
           dot1dStpBridgeMaxAge,
           dot1dStpBridgeHelloTime,
           dot1dStpBridgeForwardDelay
       }
       STATUS      current
       DESCRIPTION
           "Данные STP для устройства в целом."
       ::= { dot1dGroups 3 }

   dot1dStpPortGroup OBJECT-GROUP
       OBJECTS {
           dot1dStpPort,
           dot1dStpPortPriority,
           dot1dStpPortState,
           dot1dStpPortEnable,
           dot1dStpPortPathCost,
           dot1dStpPortDesignatedRoot,
           dot1dStpPortDesignatedCost,
           dot1dStpPortDesignatedBridge,
           dot1dStpPortDesignatedPort,
           dot1dStpPortForwardTransitions
       }
       STATUS      current
       DESCRIPTION
           "Данные STP для каждого порта устройства."
       ::= { dot1dGroups 4 }

   dot1dStpPortGroup2 OBJECT-GROUP
       OBJECTS {
           dot1dStpPort,
           dot1dStpPortPriority,
           dot1dStpPortState,
           dot1dStpPortEnable,
           dot1dStpPortDesignatedRoot,
           dot1dStpPortDesignatedCost,
           dot1dStpPortDesignatedBridge,
           dot1dStpPortDesignatedPort,
           dot1dStpPortForwardTransitions,
           dot1dStpPortPathCost32
       }
       STATUS      current
       DESCRIPTION
           "Данные STP для каждого порта устройства."
       ::= { dot1dGroups 5 }

   dot1dStpPortGroup3 OBJECT-GROUP
       OBJECTS {
           dot1dStpPortPathCost32
       }
       STATUS      current
       DESCRIPTION
           "Данные STP для устройств, поддерживающих 32-битовые
            значения стоимости пути."
       ::= { dot1dGroups 6 }

   -- ---------------------------------------------------------- --
   -- группа dot1dTp 
   -- ---------------------------------------------------------- --

   dot1dTpBridgeGroup OBJECT-GROUP
       OBJECTS {
           dot1dTpLearnedEntryDiscards,
           dot1dTpAgingTime
       }
       STATUS      current
       DESCRIPTION
           "Данные прозрачного моста для устройства в целом."
       ::= { dot1dGroups 7 }

   dot1dTpFdbGroup OBJECT-GROUP
       OBJECTS {
           dot1dTpFdbAddress,
           dot1dTpFdbPort,
           dot1dTpFdbStatus
       }

       STATUS      current
       DESCRIPTION
           "Данные Filtering Database для моста в целом."
       ::= { dot1dGroups 8 }

   dot1dTpGroup OBJECT-GROUP
       OBJECTS {
           dot1dTpPort,
           dot1dTpPortMaxInfo,
           dot1dTpPortInFrames,
           dot1dTpPortOutFrames,
           dot1dTpPortInDiscards
       }
       STATUS      current
       DESCRIPTION
           "Динамические данные Filtering Database для каждого порта."
       ::= { dot1dGroups 9 }

   -- ---------------------------------------------------------- --
   -- База данных статической фильтрации по адресам получателей
   -- ---------------------------------------------------------- --

   dot1dStaticGroup OBJECT-GROUP
       OBJECTS {
           dot1dStaticAddress,
           dot1dStaticReceivePort,
           dot1dStaticAllowedToGoTo,
           dot1dStaticStatus
       }
       STATUS      current
       DESCRIPTION
           "Статические данные Filtering Database для каждого порта."
       ::= { dot1dGroups 10 }

   -- ---------------------------------------------------------- --
   -- Группа Trap Notification
   -- ---------------------------------------------------------- --

   dot1dNotificationGroup NOTIFICATION-GROUP
       NOTIFICATIONS {
           newRoot,
           topologyChange
       }
       STATUS      current
       DESCRIPTION
           "Группа объектов, описывающих уведомления (trap)."
       ::= { dot1dGroups 11 }

   -- ---------------------------------------------------------- --
   -- заявления о соответствии
   -- ---------------------------------------------------------- --

   bridgeCompliance1493 MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "Заявление о поддержке функций моста в соответствии с RFC 1493."

       MODULE
           MANDATORY-GROUPS {
               dot1dBaseBridgeGroup,
               dot1dBasePortGroup
           }

       GROUP   dot1dStpBridgeGroup
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих протокол STP."

       GROUP   dot1dStpPortGroup
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих протокол STP."

       GROUP   dot1dTpBridgeGroup
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих прозрачный режим. Группу будут 
           реализовать прозрачные и SRT мосты."

       GROUP   dot1dTpFdbGroup
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих прозрачный режим. Группу будут 
           реализовать прозрачные и SRT мосты."

       GROUP   dot1dTpGroup
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих прозрачный режим. Группу будут 
           реализовать прозрачные и SRT мосты."

       GROUP   dot1dStaticGroup
       DESCRIPTION
           "Реализация этой группы не обязательна."

       GROUP dot1dNotificationGroup
       DESCRIPTION
           "Реализация этой группы не обязательна."
       ::= { dot1dCompliances 1 }

   bridgeCompliance4188 MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "Заявление о соответствии для устройства, поддерживающего 
           функции моста. Это включает поддержку 32-битовых значений 
           Path Cost и более ограниченные по сравнению с IEEE 802.1t
           приоритеты моста и портов.

           Полная поддержка объектов управления 802.1D требует реализации
           объектов SNMPv2-MIB [RFC3418] sysDescr и sysUpTime, а также
           объектов IF-MIB [RFC2863] ifIndex, ifType, ifDescr, 
           ifPhysAddress и ifLastChange."

       MODULE
           MANDATORY-GROUPS {
               dot1dBaseBridgeGroup,
               dot1dBasePortGroup
           }

       GROUP   dot1dStpBridgeGroup
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих протокол STP."

       OBJECT dot1dStpPriority
       SYNTAX Integer32 (0|4096|8192|12288|16384|20480|24576
                        |28672|32768|36864|40960|45056|49152
                        |53248|57344|61440)
       DESCRIPTION
           "Возможные значения определены стандартом IEEE 802.1t."

       GROUP   dot1dStpPortGroup2
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих протокол STP."

       GROUP   dot1dStpPortGroup3
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих протокол STP и 32-битовые значения
           стоимости пути. В частности, это устройства, 
           поддерживающие IEEE 802.1t и IEEE 802.1w."

       OBJECT dot1dStpPortPriority
       SYNTAX Integer32 (0|16|32|48|64|80|96|112|128
                        |144|160|176|192|208|224|240)
       DESCRIPTION
           "Возможные значения определены стандартом IEEE 802.1t."

       GROUP   dot1dTpBridgeGroup
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих прозрачный режим. Группу будут 
           реализовать прозрачные и SRT мосты."

       GROUP   dot1dTpFdbGroup
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих прозрачный режим. Группу будут 
           реализовать прозрачные и SRT мосты."

       GROUP   dot1dTpGroup
       DESCRIPTION
           "Реализация этой группы обязательна для мостов, 
           поддерживающих прозрачный режим. Группу будут 
           реализовать прозрачные и SRT мосты."

       GROUP   dot1dStaticGroup
       DESCRIPTION
           "Реализация этой группы не обязательна."

       GROUP dot1dNotificationGroup
       DESCRIPTION
           "Реализация этой группы не обязательна."
       ::= { dot1dCompliances 2 }

   END

5. Взаимодействие с IANA

Описанный в этом документе модуль MIB использует назначенное IANA значение OBJECT IDENTIFIER, записанное в реестр SMI Numbers.

 

Дескриптор

Значение OBJECT IDENTIFIER

dot1dBridge

{ mib-2 17 }

 

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

В этом модуле MIB определено множество объектов с MAX-ACCESS, разрешающим запись (read-write и/или read-create). Такие объекты могут быть уязвимыми в некоторых сетевых средах. Поддержка операций SET в небезопасной среде без подобающей защиты может оказывать негативное влияние на работу сети.

Некоторые из доступных для чтения объектов в данном модуле MIB (объекты, у которых MAX-ACCESS отличается от not-accessible), могут быть уязвимыми в некоторых сетевых средах. Важно контролировать даже операции GET и/или NOTIFY для таких объектов и возможно даже шифровать их значения при передаче через сеть по протоколу SNMP.

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

  • Открытые для записи объекты dot1dStpPriority, dot1dStpBridgeMaxAge, dot1dStpBridgeHelloTime, dot1dStpBridgeForwardDelay, dot1dStpPortPriority, dot1dStpPortEnable, dot1dStpPortPathCost и dot1dStpPortPathCost32 влияют на протокол STP. Несанкционированная запись в эти объекты может привести к изменению принятой по умолчанию топологии или повлиять на скорость расчета остовного дерева.

  • Открытый для записи объект dot1dTpAgingTime управляет сроком старения определенной динамически информации о пересылке. Установка слишком большого значения может упростить организацию атак с переполнением таблицы пересылки.

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

  • Открытые для чтения объекты в модуле BRIDGE-MIB содержат информацию о сети на базе мостов и подключенных к ней активных станциях. Адреса в таблице dot1dTpFdbTable обычно показывают производителя оборудования MAC и это может помочь при организации атак.

  • Два уведомления newRoot и topologyChange, передаваемые в процессе расчета STP, могут инициировать проверку системой управления состояния мостов и перерасчета внутренней топологической информации. Это позволяет с помощью обманных уведомлений вынудить систему управления выполнять ненужные расчеты и генерировать дополнительный трафик SNMP, направленный мостам сети. Такие ложные уведомления могут быть частью атаки на отказ сетевых служб.

Протокол SNMP до версии SNMPv3 не обеспечивает адекватной защиты. Даже в защищенной сети (например, с помощью IPSec) нет возможности персонально контролировать доступ GET/SET (чтение, изменение, создание, удаление) к объектам данного модуля MIB.

Разработчикам рекомендуется рассмотреть функции защиты, обеспечиваемые SNMPv3 (см. раздел 8 [RFC3410]), включая полную поддержку криптографических механизмов SNMPv3 (для аутентификации и конфиденциальности).

Более того, развертывание версий SNMP до SNMPv3 не рекомендуется. Вместо этого рекомендуется использовать SNMPv3 и включать криптографическую защиту. Тогда на абонентов/операторов ложится ответственность за обеспечение того, чтобы объект SNMP, предоставляющий доступ к экземпляру этого модуля MIB, был правильно настроен для предоставления доступа к объектам лишь тем элементам (пользователям), которые имеют легитимные права выполнять операции GET или SET (изменить, создать, удалить).

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

Представленный здесь модуль MIB является трансляцией модуля BRIDGE-MIB, определенного в [RFC1493], с использованием синтаксиса SMIv2. Авторами исходного модуля SMIv1 были E. Decker, P. Langille, A. Rijsinghani и K. McCloghrie. Большое спасибо членам исходной рабочей группы Bridge за подготовку [RFC1493].

Документ был подготовлен от имени рабочей группы Bridge MIB в рамках направления Operations and Management под эгидой IETF. Авторы благодарны членам группы Bridge MIB, особенно Mike MacFadden, John Flick и Bert Visscher за их замечания и предложения, которые позволили улучшить документ. Juergen Schoenwaelder помог подготовить документ к публикации.

8. Контактная информация

Основной вклад в создание исходной версии этого документа внесли четыре человека, перечисленных ниже.

E. Decker

P. Langille

A. Rijsinghan

Accton Technology Corporation

5 Mount Royal Ave

Marlboro, MA 01752

USA

K. McCloghrie

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134

USA

Преобразование в формат SMIv2 обеспечили перечисленные ниже участники работы.

Kenyon C. Norseth

L-3 Communications

640 N. 2200 West

Salt Lake City, Utah 84116-0850

USA

E. Bell

3Com Europe Limited

3Com Centre, Boundary Way

Hemel Hempstead Herts. HP2 7YU

UK

9. Отличия от RFC 1493

Ниже перечислены изменения, внесенные в RFC 1493.

  1. Определения MIB переведены в SMIv2. Это включает добавление заявлений о совместимости. Определения ASN.1 были преобразованы в тестовые соглашения, а также добавлено несколько пунктов UNITS.

  2. Добавлен объект dot1dStpPortPathCost32 для поддержки IEEE 802.1t.

  3. Разрешенные значения dot1dStpPriority и dot1dStpPortPriority были дополнительно разъяснены для мостов, поддерживающих IEEE 802.1t или IEEE 802.1w.

  4. Разъяснена интерпретация dot1dStpTimeSinceTopologyChange для мостов, поддерживающих протокол RSTP.

  5. Обновлен вводный текст шаблона, раздел, посвященный безопасности и ссылки с учетом стандартов и рекомендаций IETF.

  6. Обновлены ссылки на документы IEEE 802.1d.

  7. Дополнения и разъяснения в текстах описаний.

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

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

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

[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Textual Conventions for SMIv2», STD 58, RFC 2579, April 1999.

[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Conformance Statements for SMIv2», STD 58, RFC 2580, April 1999.

[RFC3418] Presuhn, R., «Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3418, December 2002.

[RFC2863] McCloghrie, K. and F. Kastenholz, «The Interfaces Group MIB», RFC 2863, June 2000.

[IEEE8021D] IEEE Project 802 Local and Metropolitan Area Networks, «ANSI/IEEE Standard 802.1D-1998 MAC Bridges», March 1998.

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

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, «Introduction and Applicability Statements for Internet-Standard Management Framework», RFC 3410, December 2002.

[RFC1493] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, «Definitions of Managed Objects for Bridges», RFC 1493, July 1993.

[RFC1525] Decker, E., McCloghrie, K., Langille, P., and A. Rijsinghani, «Definitions of Managed Objects for Source Routing Bridges», RFC 1525, September 1993.

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

Kenyon C. Norseth (редактор)

L-3 Communications

640 N. 2200 West

Salt Lake City, Utah 84116-0850

USA

Phone: +1 801-594-2809

EMail: kenyon.c.norseth@L-3com.com

E. Bell (редактор)

3Com Europe Limited

3Com Centre, Boundary Way

Hemel Hempstead Herts. HP2 7YU

UK

Phone: +44 1442 438025

EMail: elbell@ntlworld.com


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

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

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Management Information Base — база данных для управления.

2Simple Network Management Protocol.

3Structure of Management Information — структура управляющей информации.

4Spanning Tree Protocol — протокол остовного (связующего) дерева.

5Rapid Spanning Tree Protocol — ускоренный протокол остовного дерева.