На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

СОДЕРЖАНИЕ  СООБЩЕНИЙ S-HTTP

Содержание сообщения в большой степени зависит от значений полей Content-Privacy-Domain и Content-Transfer-Encoding. Для сообщения PKCS-7 (поле Content-Transfer-Encoding содержит строку "8BIT") содержанием сообщения является само сообщение PKCS-7. Если же поле Content-Transfer-Encoding содержит строку то (в соответствии с RFC 1421) перед содержанием сообщения дол­жна стоять следующая строка:
- BEGIN PRIVACY-ENHANCED MESSAGE -После нее должна стоять строка:
- END PRIVACY-ENHANCED MESSAGE -
В этом случае вы должны преобразовать первоначальное содержание к представ­лению base-64. Еели внутреннее (защищенное) содержание является сообщени­ем PKCS-7, то нужно соответственно установить Content-Type внешней инкапсу­ляции (оно должно равняться значению Content-Type внешнего содержания). В противном случае вам придется представить Content-Type как "Data". Если в поле Content-Privacy-Domain стоит значение РЕМ, то (согласно RFC 1421) содержа­ние должно состоять из обычного инкапсулированного сообщения. Перед ним должна стоять строка:
- BEGIN PRIVACY-ENHANCED MESSAGE -После содержания должна стоять строка:
- END  PRIVACY-ENHANCED  MESSAGE -
Полученное после удаления всех средств защиты информации (возможно, защи­щенное) содержание должно быть обычным HTTP-запросом. Однако в сообще­нии может содержаться и еще одно сообщение S-HTTP. В этом случае вам придется распаковывать его до тех пор, пока у вас не будет обычное содержание или вы будете не в состоянии продолжать распаковку. (В S-HTTP включена поддержка многоуровневой инкапсуляции данных, с помощью которой можно использовать последовательно средства создания подписей.) Как бы там ни было, но в конце концов у вас должен получиться обычный запрос (или ответ) HTTP
(если в строке Content-Type не указано иного).
Обратите внимание на что при помощи рекурсивной инкапсуляции сообще­ния можно добавить (или удалить) средства обеспечения безопасности, что су­щественно улучшит работу промежуточных участников соединения, вроде сер­вера-посредника, требующего идентификации клиента.
S-HTTP и   Content-Privacy-Domai РЕМ
РЕМ Content-Privacy-Domain нужен для использования прямых сообщений РЕМ.
Обратите внимание на то, что клиенты и серверы, реализующие протоколы идентификации доступа протокола HTTP (вроде предложенного Тони Сандерсом и реализованного Робом Маккулом), могут быть преобразованы для использования S-HTTP (при помощи строки Content-Privacy-Domain). Для этого нужно изме­нить строки запрос/результат так, чтобы они соответствовали протоколу S-HTTP, и добавить к заголовку следующие три строки:
Content-Privacy-Domain:РЕМ Content-Type: application/http
Content-Transfer-Encoding, 7В.Т § |g
Кроме того, неплохо бы (однако совсем необязательно) удалить строку authorization.
СООТВЕТСТВИЯ МЕЖДУ РЕМ и РЕЖИМАМИ S-HTTP
После РЕМ Content-Privacy-Domain обязательно должны стоять режимы защиты сообщений S-HTTP. Другими словами, и для подписанных при помощи РЕМ-ре-жима MICONLY(wnMIC-CLEAR)coo6menw S-HTTP, и для сообщений S-HTTP, зашифрованных и подписанных при помощи обмена ключей RSA, используется неверно названный режим ENCRYPTED.
СОГЛАСОВАНИЕ в S-HTTP
Стандарты S-HTTP требуют, чтобы обе стороны могли выразить свои требова­ния и предпочтения. Другими словами, стороны должны уметь сказать друг дру­гу, какое из средств шифрования должно быть использовано. Выбор средств зависит от реализации возможностей и требований конкретного приложения.
Для передачи возможностей и требований в S-HTTP используется блок согласо­вания. Блок согласования — это последовательность спецификаций, удовлетво­ряющих описанию входных данных блока.
Компонент_Описание_
Здесь располагается параметр, требующий согласования. Например, в качестве такого параметра можно указать алгоритм шифрования.
Согласовываемое значение параметра. Например,
при согласовании параметра DES в поле Value, скорее всего, будет стоять значение DES-CBC.
Направление: прием или передача (по отношению
к согласовывающему). Другими словами, если броузер хочет зашифровать сообщение при помощи
некоторого стандарта, то в качестве направления должно стоять указание на передачу.
Сила предпочтений хоста. Это поле может принимать .три значения: required, optional или refused._
Компоненты спецификаций блока согласования.
Далее приводится заголовок согласования, указывающий серверу, что он может использовать алгоритмы кодирования DES-CBC или КС4:
SHTTP-Symmetric-Content-Algorithms: recv-optibnal=DES-CBC,RC4
Для согласования информации, хранящейся в блоке согласования, в S-HTTP
добавлены новые строки заголовка (которые используются внутри инкапсулиро­ванного заголовка HTTP, а не в заголовке S-HTTP).
Property
Value
Direction
Strength


ФОРМА т ЗА ГОЛОВКА      А СОВАНИЯ
Общий формат заголовка согласования выглядит следующим образом:
<Line> := <Field> ' : ' <Key-val>('; '<Key-val»* <Key-val> := <Key> '=' <Value>(1,'<Value>)* <Key> := <Mode>' -' <Action> <Mode> : = 'orig'|'recv1
<Action> : = 'optional1|'required'| 'refused'
Значение <Mode 5 определяет действия агента, посылающего расширенные со­общения (в противоположность приему сообщений). В таблице 7.3 приведены описания, помещаемые хостом в качестве значений расширений (<Value>).
Значение расширения Описание
recv-optionai Агент должен обработать расширение в том случае,
если оно используется другой стороной. Кроме того, он должен обрабатывать сообщения без рас­ширений.
recv-required Агент не должен обрабатывать сообщения без расширения
recv-refused Агент не должен обрабатывать сообщения с расширением  < Value >.
orig-optiona, Встретив агента, не работающего с (необязательным) расширением, агент не будет предоставлять это расширение. Встретившись с агентом,
требующим использования расширений, наш агент должен обеспечить расширение.
Агент всегда должен генерировать расширение.
orig-refi/sei_Агент никогда не должен генерировать расширение.
Значения расширений для пары <Mode>/<Action>.
Как агенты будут вести себя, если им встретится несовместимый агент, зависит от самого агента. Не очень-то разумно использовать поведение, не воспринимае­мое другой стороной. Хорошие ответы должны включать в себя разрыв соедине­ния или (в случае ответа сервера) возврат "Not implemented 501".
В таблице 7.3 приведен атисок необязательных значений агента. Элементы списка располагаются в порядке убывания полезности. Однако агенты свободны в вы­боре любого (либо никакого) из элементов списка. Если какое-либо значение не то предполагается, что ему присвоено установленное
по умолчанию значение. Однако каждый указанный агентом ключ должен ис­пользоваться вместо соответствующего установленного по умолчанию значения.
заголовки согласования
Все описанные ниже заголовки согласования могут применяться ко всему доме­ну секретности (форматы сообщения) либо только к одному из них. Чтобы ука­зать параметры, согласовывающиеся для всех доменов секретности, передавае­мые данные должны содержать строки заголовка, стоящие до первого указателя домена. Считается, что заголовки согласования, после заголовка домена, относятся только к этому домену. В разрешается использовать несколько заголовков доменов для одного и того же домена секретности. Благо­даря этому можно использовать комбинации различных параметров.
В заголовке указывается, какой тип сертификатов открытых ключей воспринимает агент. В настоящее время определено только одно значение этого заголовка — Х.509. Заголовок S- НТГР-Key-Exchange-Algorithms указывает, какой из алгоритмов обмена ключами можно использовать. Для это­го заголовка определены значения и сия>". Значение "RSA" относится к методу шифрования RSA. Значение "outband" указывает на использование одного из типов соглашений о внешних ключах. Каждое из значений "Inband" и "Kerberos" относится к соответствующему про­токолу обмена ключей. Ниже приведена наиболее распространенная конфигу­рация для клиентов без сертификатов и серверов с сертификатами (сообщение, посланное сервером):
SHTTP-Key-Exchange-Algorithms; orig-optional=Inband, RSA; recv-required=RSA
Заголовок определяет, какой из алгоритмов создания цифровой подписи может быть использован обоими хостами. Для этого за­головка определены значения "RSA" и "NIST-DSS". Так как в этих алгоритмах используются ключи разной длины, то отправитель должен указать получателю длину используемого ключа. Заметьте: спецификация длины ключа зависит от возможности (или невозможности) использования определенного вида серти­фиката. Дело в том, что сертификаты открытых ключей определяют сами ключи (и их длину).
В заголовке указывается, какой алгоритм профиля сообщения может быть использован. Для этого заголовка определены зна­чения "RSA-MD2", "RSA-MD5" и "NIST-SHS".
Заголовок определяет алгоритм с симметричным ключом, используемый для шифрования содержания сообщения. В
таблице 7.4 приведен список различных значений этого заголовка.
Параметр Лн/Л key patterns определяет имена, необходимые для использования идентификаторов MAC. Синтаксис pattern-info состоит из нескольких обычных выражений, разделенных запятыми. Если в выражении должна стоять запятая, то вместо разделительных запятых можно поставить обратную косую черту. В прото­коле S-HTTP предпочтительным является использование первого шаблона.
Параметр Signing Key Pattern описывает шаблон (или шаблоны), при использовании которых можно пересылать ключи хосту. (Напоминаем, что эти ключи будут использованы для создания цифровой подписи.) Синтаксис pattern-info:
<pattern-info> := <имя-домека>,<даиные-шаблона>
В настоящее время определено только одно имя домена: 1485. Этот параметр указывает необходимые значения для полей DN (Distinguished Names). Документ RFC-1485 определяет, как протоколы Internet должны представлять DN. В частно­сти, в RFC-1485 указано, что порядок полей и разделяющих их промежутков может быть произвольным. Pattern-data — это измененная строка RFC-1485.-В S-HTTP в качестве значений полей можно использовать обычные выражения. Использование шаблонов происходит по старшинству; считается, что неопределен­ные поля соответствуют любым данным (т. е. если поле будет пустым, то разрешено использование любых DN). Кроме того, <pattern-data> могут соответствовать последовательностям сертификатов (чтобы позволить серверу воспринимать серти­фикаты без соблюдения их порядка подчинения). В S-HTTP последовательнос­ти DN читаются слева направо. При этом сразу за именем сертификата должен стоять его издатель. Однако ссылка на издателя не является обязательной.
Значения <pattern-data* имеют следующий синтаксис:
Чтобы попросить другого агента создавать подписи при помощи ключа, серти­фицированного компанией RSA Persona CA (в котором используется порядок
подчинения имен), нужно воспользоваться приведенным ниже выражением.
Для использования запятой в RFC-1485 применяется стандартный разделитель — кавычки, а в POSIX 1003.2 кавычки служат для использования точек (применяе­мый в обычных выражениях метасимвол).
Your-Key-Pattern: DN-1485,
/OU=Persona Certificate,  0="Jamsa Press\."/
Параметр шаблона Kerberos ID Pattern указывает отправителю сообщения исполь­зуемую область действия (realm) Kerberos. Заголовки согласования ссылаются на эту область в форме имени администратора доступа Kerberos:
<user>@<realm>
СТРОКИ ЗАГОЛОВКА S-HTTP
В S-HTTP есть несколько строк заголовка, входящих в блок заголовка HTTP (т. е. они входят в зашифрованное содержание сообщения). Таким образом, пользователю предоставляется возможность защитить строки заголовка при помощи шифрования. В их число входят заголовки Security-Scheme и Encryption-Identity, а также name-class.
Строка заголовка Security-Schemt обязательна: в ней указывается версия протокола (несмотря на то, что она может использоваться другими протоколами безопас­ности). Чтобы работать с протоколом S-HTTP, каждый агент должен поместить в этот заголовок строку «S-HTTP/1.1». Заголовок Security-Scheme является обязатель­ным заголовком протокола HTTP — агент, работающий с протоколом S-HTTP, должен вставлять эту строку как в сообщения S-HTTP, так и в сообщения HTTP.
Строка заголовка определяет возможного администратора до-
ступа, сообщения для которого можно зашифровывать при помощи описанных параметров. Этот заголовок позволяет использовать обратное шифрование при помощи открытого ключа (при этом другой агент не должен создавать подпись первым) или при помощи ключа, отличного от используемого для подписи. При использовании системы Kerberos заголовок Encryption-Identit предоставляет информацию о подлинности агента. Этот заголовок имеет следующий синтаксис:
Encryption-Identity: <имя-класса>,<селектор-ключа>, <имя-аргумента> I <имя-класса> : = 'DN-1485'   | 'krMD-'<kv>
имя-класса — это ASCII-строка, представляющая домен, в котором это имя может быть интерпретировано. В настоящее время распознает и определяет
только два имени классов: DN-1485 и KRB-<4,5>. селектор-ключа — это селек­тор ключей, привязанных к той же форме имен. Если форма содержит только один ключ, то броузер и сервер должны игнорировать поле селектора ключа. имя-аргумента — это соответствующий имени класса аргумент (см. далее).
DN-1485 — это зашифрованное при помощи алгоритма RFC-1485 имя DN. Ар­гумент имени класса KRB-* — это имя администратора доступа Kerberos:
<Cert-Fmt> - это тип <Cert-Group>, представляемый отправителем. Допусти­мыми значениями являются РЕМ и PKCS-7. В S-HTTP группа сертификатов PKCS-7 представляет сообщение PKCS-7 SignedData, зашифрованное при по­мощи base-64. В нем содержатся последовательности сертификатов вместе с полем SignerInfo(wm без него). Группа сертификатов формата РЕМ - это спи­сок разделенных запятыми сертификатов РЕМ, закодированных при помощи base-64. Любой из хостов может определить несколько строк Certificate-Info.
ЗАГОЛОВОК KEY-ASSIGN
Этот заголовок указывает, что агент хочет присоединить ключ к символическому имени последней ссылки. Общий синтаксис заголовка Key-Assign выглядит так:
Key-Assign: <Мешод>,<Имя-ключа>,<Время-жизни>,<Шифры>;
Строка Имя-ключа — это символическое имя, к которому S-HTTP привязывает назначенный ключ. Шифры содержат список шифров, в которых можно приме­нять назначенный ключ. Если этот ключ нельзя использовать ни в одном из шифров, то следует использовать ключевое слово NULL. Оно особенно полезно для обмена ключами алгоритма MAC.
Бремя-жизни представляет наибольший период времени, в течение которого от­правитель будет использовать этот ключ. Значение this указывает получателю, что отправитель допускает этот ключ только для чтения этой порции информа­ции. Значение reply указывает, что ключ используется только для отклика на это сообщение (или в качестве продолжительности соединения для версий HTTP, поддерживающих неразрываемые соединения). Время жизни отклика показыва­ет, что ключ будет работать как минимум для одной (но возможно, что только для одной) повторной ссылки сообщения. Время действия ключа reply сверх одной передачи (если возможно) уникально для каждой установки S-HTTP,
Метод — это один из методов обмена ключей. В настоящее время для него определены значения «inband», «krb-4» и «krb-5», относящиеся соответственно к методам обмена ключей во время передачи, а также версиям 4 и 5 системы Kerberos. В зависимости от того, какой из методов использует отправитель со­общения, оно может принимать один или более параметров аргументы-метода. Эти параметры располагаются в строке заголовка.
Строка Key-Assign может располагаться в неинкапсулированном заголовке или инкапсулированном сообщении. Тем не менее если незашифрованный ключ назначается прямыми методами, то этот заголовок может стоять только в зашиф­рованном, инкапсулированном блоке содержания. Если присвоить (при помощи заголовка Key-Assign) существующему ключу новое значение, то S-HTTP придет­ся переписать ссылку на него. Определенные при помощи заголовка Key-Assign ключи в этой главе обозначаются как Key-ID. Ниже приведен их синтаксис:
<Key-ID> : = <мв!год>' : '<имя-ключа>
ИСПОЛЬЗОВАНИЕ НАЗНАЧЕНИЯ КЛЮЧЕЙ во  ВРЕМЯ ПЕРЕДАЧИ
Назначение ключей во время передачи - это метод, при котором незашифрован­ный ключ присваивается (назначается) символическому имени. тода должны содержать только ожидаемый одноразовый ключ (в шестнадцати­ричном представлении):
Key-Assign: inband,akey,reply,DES-ЕСВ;0123456789abcdef
Приложение S-HTTP должно производить короткие ключи от длинных. Для этого оно должно считывать биты слева направо. Обратите внимание: назначение ключей, передаваемых методом во время передачи, очень важно для использования случайных конфиденциальных сообщений между агентами, в которых один (но не оба) из агентов обладает парой ключей. Однако механизм назначения ключей во время передачи также полезен при обмене ключей без вычислений открытых ключей. Информация о ключах переносится в строке заголовка Key-Assign inband. Она должна располагаться во внутреннем (защищенном) запросе HTTP. Имен­но поэтому при помощи данного ключа нельзя расшифровать все сообщение -должен быть еще один ключ.
ИСПОЛЬЗОВАНИЕ   НАЗНАЧЕНИЯ   КЛЮЧЕЙ KERBEROS
Назначение ключей Kerberos обеспечивает возможность привязки к символическо­му имени ключа совместно используемых секретов, созданных при помощи пары билет/идентификатор (напоминаем, что речь идет о методе Kerberos). В случае установки Key-Assign Kerberos аргументы-методадолжны представлять собой пару билет/идентификатор (зашифрованных при помощи base-64). Члены пары дол­жны отделяться друг от друга при помощи запятых:
Key-Assign: krb-4 , akerbkey, reply, DES-ECB;<krb-ticket>,<krb-auth>
ИСПОЛЬЗОВАНИЕ   ВРЕМЕННЫХ ИДЕНТИФИКАТОРОВ S-HTTP
Временные идентификаторы — это непостоянные, используемые только в тече­ние одного сеанса идентификаторы, которые можно применять для демонстра­ций состояния соединения — т. е. таким образом можно проверить, что никто не изменяет передаваемые данные. В S-HTTP значения временных идентифи­каторов являются локальными сущностями. Кроме того, эти значения могут быть случайными числами, генерируемыми отправителем. Отправитель пересы­лает это значение получателю, чтобы тот просто переслал его обратно. Отправи­тель использует заголовок Nonce, для того чтобы указать, какое значение должен вернуть получатель. В поле Nonce может размещаться любое значение. Более того, можно использовать несколько строк заголовка Nonce в одном передаваемом сообщении. Каждый из них должен быть возвращен получателем. Чтобы вер­нуть отправителю значение, посланное в поле Nonce или в атрибуте HTML-анкера, воспользуйтесь строкой заголовка Nonce-Echo.
РАБОТА с SERVER STATUS ERROR REPORTS
В S-HTTP существует метод, с помощью которого клиент может посылать по­вторные запросы в ответ на сообщение сервера об ошибке. Прежде всего, нуж­но попробовать провести повторное согласование. Сервер может ответить на клиентский запрос сообщением об ошибке и в том случае, если требуется по­вторный запрос. В HTTP реализован принцип перенаправления запросов при помощи специальных кодов (ЗХХ).
В S-НТТР возможны (и часто применяются) ситуации, когда серверу нужно, чтобы клиент сделал повторный запрос с другим набором параметров шифрова­ния. Например, документ, в котором содержится анкер (к которому повторно обратился клиент), может оказаться старым. В этом случае в запросе не нужно использовать цифровую подпись. Однако сервер может потребовать подпись и для повторной ссылки на этого документа. Таким образом, и в этом случае клиент должен предоставить цифровую подпись. Инкапсулированный заголовок HTTP-сообщения от сервера клиенту будет содержать параметры, вроде переуста­новки или повторной посылки запросов с дополнительным шифрованием, — точно такие же, как и у клиента.
Основная цель дополнительной информации ответов — сделать так, чтобы сер­вер помог клиенту повторить запрос. Более того, цель сервера — помочь клиен­ту сделать повторный запрос так, чтобы в нем использовались параметры перво­го запроса, причина ошибки и средства шифрования — в зависимости от поме­щенных в ответ сервера параметров.
Основной принцип ответа клиента на сообщение об ошибке состоит в том, что­бы предоставить пользователю тот же тип выбора. Это делается, для того чтобы пользователь мог повторно ссылаться на анкеры так, как будто он производит это обычным способом. Рассмотрим следующий случай. В предыдущем примере
мы пытались повторно заполучить документ, требующий использования цифровой подписи. В подобных случаях пользователь не может создать подпись запроса без предварительного разрешения сервера.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика