RFC2660 日本語訳
2660 The Secure HyperText Transfer Protocol. E. Rescorla, A.Schiffman. August 1999. (Format: TXT=95645 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Rescorla
Request for Comments: 2660 RTFM, Inc.
Category: Experimental A. Schiffman
Terisa Systems, Inc.
August 1999
コメントを求めるワーキンググループE.レスコラの要求をネットワークでつないでください: 2660年のRTFM Inc.カテゴリ: 実験的なA.シフマンTerisaシステムInc.1999年8月
The Secure HyperText Transfer Protocol
安全なハイパーテキスト転送プロトコル
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin.
このメモはWWWの基礎を形成するハイパーテキストTransferプロトコル(HTTP)が使用させられるメッセージを保証するための構文について説明します。 安全なHTTP(S-HTTP)は発生源のトランザクション秘密性、信憑性/保全、および非repudiabilityに独自に適用されるセキュリティー・サービスを供給します。
The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction.
各トランザクションのためにオプションがパーティーの間の交渉であるとサポートすることによって、プロトコルはかぎ管理メカニズムの選択、安全保障政策、および暗号アルゴリズムで最大の柔軟性を強調します。
Table of Contents
目次
1. Introduction .................................................. 3 1.1. Summary of Features ......................................... 3 1.2. Changes ..................................................... 4 1.3. Processing Model ............................................ 5 1.4. Modes of Operation .......................................... 6 1.5. Implementation Options ...................................... 7 2. Message Format ................................................ 7 2.1. Notational Conventions ...................................... 8 2.2. The Request Line ............................................ 8 2.3. The Status Line ............................................. 8 2.4. Secure HTTP Header Lines .................................... 8 2.5. Content .....................................................12 2.6. Encapsulation Format Options ................................13
1. 序論… 3 1.1. 特徴の概要… 3 1.2. 変化… 4 1.3. 処理モデル… 5 1.4. 操作のモード… 6 1.5. 実装オプション… 7 2. メッセージ形式… 7 2.1. 記号法のコンベンション… 8 2.2. 要求線… 8 2.3. 状況表示行… 8 2.4. HTTPヘッダ線を固定してください… 8 2.5. 内容…12 2.6. カプセル化形式オプション…13
Rescorla & Schiffman Experimental [Page 1] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[1ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
2.6.1. Content-Privacy-Domain: CMS ...............................13 2.6.2. Content-Privacy-Domain: MOSS ..............................14 2.6.3. Permitted HTTP headers ....................................14 2.6.3.2. Host ....................................................15 2.6.3.3. Connection ..............................................15 3. Cryptographic Parameters ......................................15 3.1. Options Headers .............................................15 3.2. Negotiation Options .........................................16 3.2.1. Negotiation Overview ......................................16 3.2.2. Negotiation Option Format .................................16 3.2.3. Parametrization for Variable-length Key Ciphers ...........18 3.2.4. Negotiation Syntax ........................................18 3.3. Non-Negotiation Headers .....................................23 3.3.1. Encryption-Identity .......................................23 3.3.2. Certificate-Info ..........................................23 3.3.3. Key-Assign ................................................24 3.3.4. Nonces ....................................................25 3.4. Grouping Headers With SHTTP-Cryptopts .......................26 3.4.1. SHTTP-Cryptopts ...........................................26 4. New Header Lines for HTTP .....................................26 4.1. Security-Scheme .............................................26 5. (Retriable) Server Status Error Reports .......................27 5.1. Retry for Option (Re)Negotiation ............................27 5.2. Specific Retry Behavior .....................................28 5.3. Limitations On Automatic Retries ............................29 6. Other Issues ..................................................30 6.1. Compatibility of Servers with Old Clients ...................30 6.2. URL Protocol Type ...........................................30 6.3. Browser Presentation ........................................31 7. Implementation Notes ..........................................32 7.1. Preenhanced Data ............................................32 7.2. Note:Proxy Interaction ......................................34 7.2.1. Client-Proxy Authentication ...............................34 8. Implementation Recommendations and Requirements ...............34 9. Protocol Syntax Summary .......................................35 10. An Extended Example ..........................................36 Appendix: A Review of CMS ........................................40 Bibliography and References ......................................41 Security Considerations ..........................................43 Authors' Addresses ...............................................44 Full Copyright Statement..........................................45
2.6.1. 満足しているプライバシードメイン: cm…13 2.6.2. 満足しているプライバシードメイン: こけ…14 2.6.3. HTTPヘッダを可能にします…14 2.6.3.2. 接待します。15 2.6.3.3. 接続…15 3. 暗号のパラメタ…15 3.1. オプションヘッダー…15 3.2. 交渉オプション…16 3.2.1. 交渉概要…16 3.2.2. 交渉オプション形式…16 3.2.3. 可変長のキーのための助変数化は解かれます…18 3.2.4. 交渉構文…18 3.3. 譲渡禁止ヘッダー…23 3.3.1. 暗号化アイデンティティ…23 3.3.2. 証明書インフォメーション…23 3.3.3. キーアサイン…24 3.3.4. 一回だけ…25 3.4. SHTTP-Cryptoptsがあるヘッダーを分類します…26 3.4.1. SHTTP-Cryptopts…26 4. 新しいヘッダーはHTTPのために立ち並んでいます…26 4.1. 安全に計画してください…26 5. (Retriable) サーバ状態誤りは報告します…27 5.1. オプション(re)交渉には、再試行してください…27 5.2. 特定の再試行の振舞い…28 5.3. 自動再試行の制限…29 6. 他の問題…30 6.1. 年取ったクライアントとのサーバの互換性…30 6.2. URLプロトコルタイプ…30 6.3. ブラウザプレゼンテーション…31 7. 実装注意…32 7.1. データをPreenhancedしました…32 7.2. 注意: プロキシ相互作用…34 7.2.1. クライアントプロキシ認証…34 8. 実装推薦と要件…34 9. 構文概要について議定書の中で述べてください…35 10. 拡張例…36付録: cmのレビュー…40の図書目録と参照箇所…41 セキュリティ問題…43人の作者のアドレス…44 完全な著作権宣言文…45
Rescorla & Schiffman Experimental [Page 2] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[2ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
1. Introduction
1. 序論
The World Wide Web (WWW) is a distributed hypermedia system which has gained widespread acceptance among Internet users. Although WWW browsers support other, preexisting Internet application protocols, the native and primary protocol used between WWW clients and servers is the HyperText Transfer Protocol (HTTP) [RFC-2616]. The ease of use of the Web has prompted its widespread employment as a client/server architecture for many applications. Many such applications require the client and server to be able to authenticate each other and exchange sensitive information confidentially. The original HTTP specification had only modest support for the cryptographic mechanisms appropriate for such transactions.
WWW(WWW)はインターネットユーザの中で幅広い支持を得た分配されたハイパーメディアシステムです。 WWWブラウザは、他の、そして、先在のインターネットがアプリケーション・プロトコルであるとサポートしますが、WWWクライアントとサーバの間で使用されるネイティブの、そして、プライマリのプロトコルはHyperText Transferプロトコル(HTTP)[RFC-2616]です。 ウェブの使いやすさは多くのアプリケーションのためのクライアント/サーバー・アーキテクチャとして広範囲の雇用をうながしました。 そのような多くのアプリケーションが、クライアントとサーバが秘密に互いを認証して、機密情報を交換できるのを必要とします。 当初のHTTP仕様で、暗号のメカニズムの穏やかなサポートだけがそのようなトランザクションに適切になりました。
Secure HTTP (S-HTTP) provides secure communication mechanisms between an HTTP client-server pair in order to enable spontaneous commercial transactions for a wide range of applications. Our design intent is to provide a flexible protocol that supports multiple orthogonal operation modes, key management mechanisms, trust models, cryptographic algorithms and encapsulation formats through option negotiation between parties for each transaction.
安全なHTTP(S-HTTP)は、さまざまなアプリケーションのために自然発生的な商業トランザクションを可能にするためにHTTPクライアント/サーバ組の間に安全なコミュニケーションメカニズムを提供します。 私たちのデザイン意図は各トランザクションのために複数の直交した操作がモードと、かぎ管理メカニズムと、信頼モデルと、暗号アルゴリズムとカプセル化形式であるとパーティーの間のオプション交渉でサポートするフレキシブルなプロトコルを提供することです。
1.1. Summary of Features
1.1. 特徴の概要
Secure HTTP is a secure message-oriented communications protocol designed for use in conjunction with HTTP. It is designed to coexist with HTTP's messaging model and to be easily integrated with HTTP applications.
安全なHTTPは使用のためにHTTPに関連して設計された安全なメッセージ指向の通信規約です。 それは、HTTPのメッセージングモデルと共存して、容易にHTTPアプリケーションと統合されるように設計されています。
Secure HTTP provides a variety of security mechanisms to HTTP clients and servers, providing the security service options appropriate to the wide range of potential end uses possible for the World-Wide Web. The protocol provides symmetric capabilities to both client and server (in that equal treatment is given to both requests and replies, as well as for the preferences of both parties) while preserving the transaction model and implementation characteristics of HTTP.
安全なHTTPはHTTPクライアントとサーバにさまざまなセキュリティー対策を提供します、WWWに、可能な潜在的最終用途の広範囲に適切なセキュリティー・サービスオプションを提供して。 プロトコルはHTTPのトランザクションモデルと実装の特性を保存している間、クライアントとサーバの両方(要求と回答の両方、および双方の好みのために平等な待遇を与えるので)に左右対称の能力を提供します。
Several cryptographic message format standards may be incorporated into S-HTTP clients and servers, particularly, but in principle not limited to, [CMS] and [MOSS]. S-HTTP supports interoperation among a variety of implementations, and is compatible with HTTP. S-HTTP aware clients can communicate with S-HTTP oblivious servers and vice-versa, although such transactions obviously would not use S-HTTP security features.
規格がS-HTTPクライアントとサーバを組み入れて、特に、しかし、原則として制限されないかもしれない数個の暗号のメッセージ・フォーマット、[CMS]、および[モス。] S-HTTPは、さまざまな実装の中でinteroperationをサポートして、HTTPと互換性があります。 S-HTTPの意識しているクライアントはS-HTTPの忘れっぽいサーバとコミュニケートできます、そして、逆もまた同様です、そのようなトランザクションは明らかにS-HTTPセキュリティ機能を使用しないでしょうが。
S-HTTP does not require client-side public key certificates (or public keys), as it supports symmetric key-only operation modes.
左右対称のキーだけ操作がモードであるとサポートするとき、S-HTTPはクライアントサイド公開鍵証明書(または、公開鍵)を必要としません。
Rescorla & Schiffman Experimental [Page 3] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[3ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
This is significant because it means that spontaneous private transactions can occur without requiring individual users to have an established public key. While S-HTTP is able to take advantage of ubiquitous certification infrastructures, its deployment does not require it.
個々のユーザには確立した公開鍵がある必要でない自然発生的な民間取引が起こることができることを意味するので、これは重要です。 S-HTTPが遍在している証明インフラストラクチャを利用できる間、展開はそれを必要としません。
S-HTTP supports end-to-end secure transactions, in contrast with the original HTTP authorization mechanisms which require the client to attempt access and be denied before the security mechanism is employed. Clients may be "primed" to initiate a secure transaction (typically using information supplied in message headers); this may be used to support encryption of fill-out forms, for example. With S-HTTP, no sensitive data need ever be sent over the network in the clear.
S-HTTPは終わりから終わりへの安全なトランザクションをサポートします、セキュリティー対策が採用している前にクライアントがアクセスを試みて、否定されるのを必要とするオリジナルのHTTP承認メカニズムと比べて。 クライアントは安全なトランザクションを開始するために「用意されるかもしれない」(メッセージヘッダーで提供された情報を通常使用して)。 これは、例えば、必要事項を入力したフォームの暗号化をサポートするのに使用されるかもしれません。 S-HTTPと共に、今までに、明確のネットワークの上に極秘データを全く送る必要はありません。
S-HTTP provides full flexibility of cryptographic algorithms, modes and parameters. Option negotiation is used to allow clients and servers to agree on transaction modes (e.g., should the request be signed or encrypted or both -- similarly for the reply?); cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypting, etc.); and certificate selection (please sign with your "Block-buster Video certificate").
S-HTTPは暗号アルゴリズム、モード、およびパラメタの完全な柔軟性を提供します。 オプション交渉がクライアントとサーバがトランザクションモードに同意するのを許容するのに使用される、(例えば、署名されたか、または暗号化された要求か両方--、同様である、回答)?、;であるべきです 暗号アルゴリズム(RSA、対DES対暗号化のためのRC2署名のためのDSAなど)。 そして、選択を証明してください(「超大作Video証明書」と契約してください)。
S-HTTP attempts to avoid presuming a particular trust model, although its designers admit to a conscious effort to facilitate multiply-rooted hierarchical trust, and anticipate that principals may have many public key certificates.
S-HTTPは、特定の信頼モデルを推定するのを避けるのを試みます、デザイナーが容易にする意識している取り組みを認めますが掛け算、-、根づいている、階層的である、校長には多くの公開鍵証明書があるかもしれないと信じて、予期してください。
S-HTTP differs from Digest-Authentication, described in [RFC-2617] in that it provides support for public key cryptography and consequently digital signature capability, as well as providing confidentiality.
S-HTTPはDigest-認証と異なっています、公開鍵暗号とその結果デジタル署名能力のサポートを提供するので[RFC-2617]で説明されて、秘密性を提供して。
1.2. Changes
1.2. 変化
This document describes S-HTTP/1.4. It differs from the previous memo in that it differs from the previous memo in its support of the Cryptographic Message Syntax (CMS) [CMS], a successor to PKCS-7; and hence now supports the Diffie-Hellman and the (NIST) Digital Signature Standard cryptosystems. CMS used in RSA mode is bits on the wire compatible with PKCS-7.
このドキュメントはS-HTTP/1.4について説明します。 それはCryptographic Message Syntax(CMS)[CMS]のサポートにおいて前のメモと異なっているという点において前のメモと異なっています、PKCS-7の後継者。 そして、したがって、現在、デジタル署名基準暗号系RSAモードで使用されるサポートディフィー-ヘルマンと(NIST)CMSはPKCS-7とのコンパチブルワイヤのビットです。
Rescorla & Schiffman Experimental [Page 4] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[4ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
1.3. Processing Model
1.3. 処理モデル
1.3.1. Message Preparation
1.3.1. メッセージ準備
The creation of an S-HTTP message can be thought of as a a function with three inputs:
3つの入力があるa機能としてS-HTTPメッセージの作成を考えることができます:
1. The cleartext message. This is either an HTTP message
or some other data object. Note that since the cleartext message
is carried transparently, headers and all, any version of HTTP
can be carried within an S-HTTP wrapper.
2. The receiver's cryptographic preferences and keying material.
This is either explicitly specified by the receiver or subject
to some default set of preferences.
3. The sender's cryptographic preferences and keying material.
This input to the function can be thought of as implicit
since it exists only in the memory of the sender.
1. cleartextメッセージ。 これは、HTTPメッセージかデータ・オブジェクトのどちらかですある他の。 S-HTTPラッパーの中でcleartextメッセージ以来透過的に運ばれる注意とヘッダーとHTTPのどんなバージョンも運ぶことができます。 2. 受信機の暗号の好みと材料を合わせること。 これは明らかに受信機か何らかのデフォルトセットの好みを条件として指定されます。 3. 送付者の暗号の好みと材料を合わせること。 送付者の思い出だけに存在しているので、暗黙として機能へのこの入力を考えることができます。
In order to create an S-HTTP message, then, the sender integrates the sender's preferences with the receiver's preferences. The result of this is a list of cryptographic enhancements to be applied and keying material to be used to apply them. This may require some user intervention. For instance, there might be multiple keys available to sign the message. (See Section 3.2.4.9.3 for more on this topic.) Using this data, the sender applies the enhancements to the message clear-text to create the S-HTTP message.
そして、S-HTTPメッセージを作成するために、送付者は送付者の好みを受信機の好みと統合します。 この結果はそれらを適用するのに使用されるために適用されて、材料を合わせている暗号の増進のリストです。 これは何らかのユーザ介入を必要とするかもしれません。 例えば、メッセージに署名するために利用可能な複数のキーがあるかもしれません。 セクション3.2を見てください。(.4 .9 .3 この話題の以上で) このデータを使用して、送付者は、S-HTTPメッセージを作成するためにメッセージクリアテキストに増進を適用します。
The processing steps required to transform the cleartext message into the S-HTTP message are described in Sections 2 and 3. The processing steps required to merge the sender's and receiver's preferences are described in Sections 3.2.
cleartextメッセージをS-HTTPメッセージに変えるのに必要である処理ステップはセクション2と3で説明されます。 送付者と受信機の好みを合併するのに必要である処理ステップはセクション3.2で説明されます。
1.3.2. Message Recovery
1.3.2. メッセージ回復
The recovery of an S-HTTP message can be thought of as a function of four distinct inputs:
4つの異なった入力の機能としてS-HTTPメッセージの回復を考えることができます:
1. The S-HTTP message.
2. The receiver's stated cryptographic preferences and keying
material. The receiver has the opportunity to remember what
cryptographic preferences it provided in order for this
document to be dereferenced.
3. The receiver's current cryptographic preferences and
keying material.
4. The sender's previously stated cryptographic options.
The sender may have stated that he would perform certain
cryptographic operations in this message. (Again, see
sections 4 and 5 for details on how to do this.)
1. S-HTTPメッセージ。 2. 受信機は暗号の好みと合わせることの材料を述べました。 受信機には、このドキュメントが「反-参照をつけ」られるためにそれがどんな暗号の好みを提供したかを思い出す機会があります。 3. 受信機の現在の暗号の好みと材料を合わせること。 4. 送付者の以前に述べられた暗号のオプション。 送付者は、彼がこのメッセージにおける、ある暗号の操作を実行すると述べたかもしれません。 (もう一度、どうこれをするかに関する詳細に関してセクション4と5を見てください。)
Rescorla & Schiffman Experimental [Page 5] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[5ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
In order to recover an S-HTTP message, the receiver needs to read the headers to discover which cryptographic transformations were performed on the message, then remove the transformations using some combination of the sender's and receiver's keying material, while taking note of which enhancements were applied.
S-HTTPメッセージを回復するために、受信機は、どの暗号の変換がどの増進に注目しているか間に材料を合わせる送付者と受信機の何らかの組み合わせを使用することでメッセージに実行されて、次に、変換を移すかが適用されたと発見するためにヘッダーを読む必要があります。
The receiver may also choose to verify that the applied enhancements match both the enhancements that the sender said he would apply (input 4 above) and that the receiver requested (input 2 above) as well as the current preferences to see if the S-HTTP message was appropriately transformed. This process may require interaction with the user to verify that the enhancements are acceptable to the user. (See Section 6.4 for more on this topic.)
また、受信機は、S-HTTPメッセージが適切に変えられたなら適用された増進が申し込んで(上の4を入力します)送付者が彼を言った、受信機が現在の好みと同様に見るよう要求した(上の2を入力します)両方の増進に合っていることを確かめるのを選ぶかもしれません。 このプロセスは、ユーザにとって、増進が許容できることを確かめるためにユーザとの相互作用を必要とするかもしれません。 (詳しい情報については、この話題に関してセクション6.4を見てください。)
1.4. Modes of Operation
1.4. 運転モード
Message protection may be provided on three orthogonal axes: signature, authentication, and encryption. Any message may be signed, authenticated, encrypted, or any combination of these (including no protection).
3本の直交した軸の上にメッセージ保護を提供するかもしれません: 署名、認証、および暗号化。 どんなメッセージも、署名されて、認証されて、暗号化されていてこれらのどんな組み合わせであるかもしれません(ノー・プロテクションを含んでいて)。
Multiple key management mechanisms are supported, including password-style manually shared secrets and public-key key exchange. In particular, provision has been made for prearranged (in an earlier transaction or out of band) symmetric session keys in order to send confidential messages to those who have no public key pair.
手動で共有されたパスワードスタイル秘密と公開鍵の主要な交換を含んでいて、複数のかぎ管理メカニズムがサポートされます。 公開鍵組が全くいない人に秘密のメッセージを送って、特に、根回しされた(以前のトランザクションかバンドからの)左右対称のセッションキーに備えました。
Additionally, a challenge-response ("nonce") mechanism is provided to
allow parties to assure themselves of transaction freshness.
さらに、パーティーがトランザクションの新しさを自分たちに保証するのを許容するためにチャレンジレスポンス(「一回だけ」)メカニズムを提供します。
1.4.1. Signature
1.4.1. 署名
If the digital signature enhancement is applied, an appropriate certificate may either be attached to the message (possibly along with a certificate chain) or the sender may expect the recipient to obtain the required certificate (chain) independently.
デジタル署名増進が適用されているなら、適切な証明書がメッセージ(ことによると証明書チェーンに伴う)に添付されるかもしれませんか、または送付者は、受取人が独自に、必要な証明書(チェーン)を入手すると予想するかもしれません。
1.4.2. Key Exchange and Encryption
1.4.2. 主要な交換と暗号化
In support of bulk encryption, S-HTTP defines two key transfer mechanisms, one using public-key enveloped key exchange and another with externally arranged keys.
大量の暗号化を支持して、S-HTTPは2台の主要なトランスファ・メカニズム(外部的にアレンジされたキーと共に公開鍵のおおわれた主要な交換と別のものを使用する1つ)を定義します。
In the former case, the symmetric-key cryptosystem parameter is passed encrypted under the receiver's public key.
前の場合では、対称鍵暗号系パラメタは受信機の公開鍵の下で暗号化されていた状態で通過されます。
Rescorla & Schiffman Experimental [Page 6] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[6ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
In the latter mode, we encrypt the content using a prearranged session key, with key identification information specified on one of the header lines.
後者のモードで、私たちは、主要なヘッダー系列の1つで指定されている主要な識別情報で根回しされたセッションを使用することで内容を暗号化します。
1.4.3. Message Integrity and Sender Authentication
1.4.3. メッセージの保全と送付者認証
Secure HTTP provides a means to verify message integrity and sender authenticity for a message via the computation of a Message Authentication Code (MAC), computed as a keyed hash over the document using a shared secret -- which could potentially have been arranged in a number of ways, e.g.: manual arrangement or 'inband' key management. This technique requires neither the use of public key cryptography nor encryption.
安全なHTTPはメッセージのために合わせられたハッシュとしてドキュメントに関して共有秘密キー(例えば潜在的に多くの方法でアレンジされたかもしれない)を使用することで計算されたメッセージ立証コード(MAC)の計算でメッセージの保全と送付者の信憑性について確かめる手段を提供します: 手動のアレンジメントか'「不-バンド」'かぎ管理。 このテクニックは公開鍵暗号の使用も暗号化も必要としません。
This mechanism is also useful for cases where it is appropriate to allow parties to identify each other reliably in a transaction without providing (third-party) non-repudiability for the transactions themselves. The provision of this mechanism is motivated by our bias that the action of "signing" a transaction should be explicit and conscious for the user, whereas many authentication needs (i.e., access control) can be met with a lighter-weight mechanism that retains the scalability advantages of public-key cryptography for key exchange.
また、このメカニズムもパーティーがトランザクション自体のために非repudiabilityである提供(第三者)なしでトランザクションで互いを確かに特定するのを許容するのが適切であるケースの役に立ちます。 このメカニズムに関する条項はトランザクションの「署名する」である動作が明白であってユーザにとって意識し、ところが、多くの認証の必要性が(すなわち、アクセスコントロール)に会うことができる主要な交換のための公開鍵暗号のスケーラビリティ利点を保有するより軽い重さのメカニズムであるならそうする私たちの偏見によって動機づけられています。
1.4.4. Freshness
1.4.4. 新しさ
The protocol provides a simple challenge-response mechanism, allowing both parties to insure the freshness of transmissions. Additionally, the integrity protection provided to HTTP headers permits implementations to consider the Date: header allowable in HTTP messages as a freshness indicator, where appropriate (although this requires implementations to make allowances for maximum clock skew between parties, which we choose not to specify).
双方がトランスミッションの新しさを保障するのを許容して、プロトコルは簡単なチャレンジレスポンスメカニズムを提供します。 さらに、HTTPヘッダに提供された保全保護は、実装が日付:を考えることを許可します。 適切である(これは私たちが指定しないのを選ぶパーティーの間の最大の時計斜行を考慮に入れるために実装を必要としますが)ところの新しさインディケータとしてHTTPメッセージで許容できるヘッダー。
1.5. Implementation Options
1.5. 実装オプション
In order to encourage widespread adoption of secure documents for the World-Wide Web in the face of the broad scope of application requirements, variability of user sophistication, and disparate implementation constraints, Secure HTTP deliberately caters to a variety of implementation options. See Section 8 for implementation recommendations and requirements.
アプリケーション要件の広い範囲、ユーザ洗練の可変性、および異種の実装規制に直面してWWWのための安全なドキュメントの広範囲の採用を奨励するために、Secure HTTPは故意にさまざまな実装オプションに満たします。 実装推薦と要件に関してセクション8を見てください。
2. Message Format
2. メッセージ・フォーマット
Syntactically, Secure HTTP messages are the same as HTTP, consisting of a request or status line followed by headers and a body. However, the range of headers is different and the bodies are typically
シンタクス上、Secure HTTPメッセージはHTTPと同じです、ヘッダーとボディーが支えた要求か状況表示行から成って。 しかしながら、ヘッダーの範囲は異なっています、そして、ボディーは通常、異なります。
Rescorla & Schiffman Experimental [Page 7] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[7ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
cryptographically enhanced.
暗号で高められます。
2.1. Notational Conventions
2.1. 記号法のコンベンション
This document uses the augmented BNF from HTTP [RFC-2616]. You should refer to that document for a description of the syntax.
このドキュメントはHTTP[RFC-2616]から増大しているBNFを使用します。 あなたは構文の記述についてそのドキュメントを参照するべきです。
2.2. Request Line
2.2. 線を要求してください。
In order to differentiate S-HTTP messages from HTTP messages and allow for special processing, the request line should use the special Secure" method and use the protocol designator "Secure-HTTP/1.4". Consequently, Secure-HTTP and HTTP processing can be intermixed on the same TCP port, e.g. port 80. In order to prevent leakage of potentially sensitive information Request-URI should be "*". For example:
「HTTPメッセージとS-HTTPメッセージを区別して、特別な処理を考慮するために、要求系列は特別なSecureを使用するべきである」というメソッドと使用、プロトコル指示子「安全なHTTP/1.4インチ。」 その結果、例えば、同じTCPポート、ポート80の上でSecure-HTTPとHTTP処理を混ぜることができます。 潜在的に機密の情報の漏出を防ぐために、Request-URIは「*」であるべきです。 例えば:
Secure * Secure-HTTP/1.4
安全な*安全なHTTP/1.4
When communicating via a proxy, the Request-URI should be consist of the AbsoluteURI. Typically, the rel path section should be replaced by "*" to minimize the information passed to in the clear. (e.g. http://www.terisa.com/*); proxies should remove the appropriate amount of this information to minimize the threat of traffic analysis. See Section 7.2.2.1 for a situation where providing more information is appropriate.
プロキシを通って交信するとき、Request-URIはAbsoluteURIから成ることであるべきです。 通常、明確で通過された情報を最小にするためにrel経路部を「*」に取り替えるべきです。 (例えば、 http://www.terisa.com/* )。 プロキシは、トラヒック分析の脅威を最小にするためにこの情報の適切な量を取り除くべきです。 セクション7.2を見てください。.2 状況のための.1は詳しい情報を提供するところで適切です。
2.3. The Status Line
2.3. 状況表示行
S-HTTP responses should use the protocol designator "Secure- HTTP/1.4". For example:
S-HTTP応答はプロトコル指示子「安全なHTTP/1.4インチ」を使用するべきです。 例えば:
Secure-HTTP/1.4 200 OK
安全なHTTP/1.4 200OK
Note that the status in the Secure HTTP response line does not indicate anything about the success or failure of the unwrapped HTTP request. Servers should always use 200 OK provided that the Secure HTTP processing is successful. This prevents analysis of success or failure for any request, which the correct recipient can determine from the encapsulated data. All case variations should be accepted.
Secure HTTP応答系列における状態が開けられたHTTP要求の成否に関して何も示さないことに注意してください。 Secure HTTP処理がうまくいけば、サーバはいつも200OKを使用するべきです。 これはどんな要求のためにも成否の分析を防ぎます。(正しい受取人はカプセル化されたデータからそれを決定できます)。 すべてのケース変化を受け入れるべきです。
2.4. Secure HTTP Header Lines
2.4. 安全なHTTPヘッダ線
The header lines described in this section go in the header of a Secure HTTP message. All except 'Content-Type' and 'Content-Privacy- Domain' are optional. The message body shall be separated from the header block by two successive CRLFs.
このセクションで説明されたヘッダー系列はSecure HTTPメッセージのヘッダーに入ります。 'コンテントタイプと''満足しているプライバシードメイン'を除いたすべてが任意です。 メッセージ本体は2連続したCRLFsによってヘッダーブロックと切り離されるものとします。
Rescorla & Schiffman Experimental [Page 8] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[8ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
All data and fields in header lines should be treated as case insensitive unless otherwise specified. Linear whitespace [RFC-822] should be used only as a token separator unless otherwise quoted. Long header lines may be line folded in the style of [RFC-822].
別の方法で指定されない場合、ヘッダー系列におけるすべてのデータと分野は大文字と小文字を区別しないとして扱われるべきです。 別の方法で引用されない場合、直線的な空白[RFC-822]は単にトークン分離符として使用されるべきです。 長いヘッダー系列は[RFC-822]のスタイルで折り重ねられた系列であるかもしれません。
This document refers to the header block following the S-HTTP request/response line and preceding the successive CRLFs collectively as "S-HTTP headers".
このドキュメントはS-HTTP要求/応答系列に続いて、「S-HTTPヘッダ」として連続したCRLFsにまとめて先行するヘッダーブロックを示します。
2.4.1. Content-Privacy-Domain
2.4.1. 満足しているプライバシードメイン
The two values defined by this document are 'MOSS' and 'CMS'. CMS refers to the privacy enhancement specified in section 2.6.1. MOSS refers to the format defined in [RFC-1847] and [RFC-1848].
このドキュメントによって定義された2つの値が、'モス'と'CMS'です。 CMSはセクション2.6.1で指定されたプライバシー増進について言及します。 モスは[RFC-1847]と[RFC-1848]で定義された書式を示します。
2.4.2. Content-Type for CMS
2.4.2. cmコンテントタイプ
Under normal conditions, the terminal encapsulated content (after all privacy enhancements have been removed) would be an HTTP message. In this case, there shall be a Content-Type line reading:
正常な状況では、内容(すべてのプライバシー増進を取り除いた後に)であることがカプセルに入れられた端末はHTTPメッセージでしょう。 この場合、読むコンテントタイプ系列があるでしょう:
Content-Type: message/http
コンテントタイプ: メッセージ/http
The message/http content type is defined in RFC-2616.
メッセージ/http content typeはRFC-2616で定義されます。
If the inner message is an S-HTTP message, then the content type shall be 'application/s-http'. (See Appendix for the definition of this.)
内側のメッセージがS-HTTPメッセージであるなら、content typeは'アプリケーション/s-http'でしょう。 (この定義に関してAppendixを見てください。)
It is intended that these types be registered with IANA as MIME content types.
これらのタイプがMIME content typeとしてIANAに示されることを意図します。
The terminal content may be of some other type provided that the type is properly indicated by the use of an appropriate Content-Type header line. In this case, the header fields for the encapsulation of the terminal content apply to the terminal content (the 'final headers'). But in any case, final headers should themselves always be S-HTTP encapsulated, so that the applicable S-HTTP/HTTP headers are never passed unenhanced.
タイプが適切なコンテントタイプヘッダー系列の使用で適切に示されれば、ある他のタイプには端末の内容があるかもしれません。 この場合、端末の内容のカプセル化のためのヘッダーフィールドは端末の内容('最終的なヘッダー')に適用されます。 しかし、どのような場合でも、最終的なヘッダーがそうするべきである、自分たち、いつもカプセル化されたS-HTTPになってください、適切なS-HTTP/HTTPヘッダが「非-高め」られた状態で決して通過されないように。
S-HTTP encapsulation of non-HTTP data is a useful mechanism for passing pre-enhanced data (especially presigned data) without requiring that the HTTP headers themselves be pre-enhanced.
非HTTPデータのS-HTTPカプセル化は、HTTPヘッダ自体があらかじめ高められる必要でないあらかじめ高められたデータ(特に前署名しているデータ)を通過するための役に立つメカニズムです。
Rescorla & Schiffman Experimental [Page 9] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[9ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
2.4.3. Content-Type for MOSS
2.4.3. こけのためのコンテントタイプ
The Content-Type for MOSS shall be an acceptable MIME content type describing the cryptographic processing applied. (e.g. multipart/signed). The content type of the inner content is described in the content type line corresponding to that inner content, and for HTTP messages shall be 'message/http'.
モスが暗号の処理について説明する許容できるMIME content typeになるので、コンテントタイプは適用されました。 (例えば、複合/は署名しました。) 内側の内容のcontent typeは、その内側の内容に対応するcontent type系列で説明されて、HTTPメッセージへの'になるでしょう'メッセージ/http。
2.4.4. Prearranged-Key-Info
2.4.4. 根回しされた主要なインフォメーション
This header line is intended to convey information about a key which has been arranged outside of the internal cryptographic format. One use of this is to permit in-band communication of session keys for return encryption in the case where one of the parties does not have a key pair. However, this should also be useful in the event that the parties choose to use some other mechanism, for instance, a one-time key list.
このヘッダー系列が内部の暗号の形式の外に配置されたキーの周りで情報を伝達することを意図します。 これの1つの使用はバンドにおける、パーティーのひとりが主要な組いない場合におけるリターン暗号化のためのセッションキーに関するコミュニケーションを可能にすることです。 しかしながら、また、パーティーが、ある他のメカニズム、例えば1回の主要なリストを使用するのを選ぶ場合、これも役に立つべきです。
This specification defines two methods for exchanging named keys, Inband, Outband. Inband indicates that the session key was exchanged previously, using a Key-Assign header of the corresponding method. Outband arrangements imply that agents have external access to key materials corresponding to a given name, presumably via database access or perhaps supplied immediately by a user from keyboard input. The syntax for the header line is:
この仕様はキーという交換、Inband、Outbandのために2つのメソッドを定義します。 対応するメソッドのKey-案配ヘッダーを使用して、Inbandは、セッションキーが以前に交換されたのを示します。 Outbandアレンジメントは、エージェントが名におそらくデータベースアクセスを通して対応するか恐らくすぐユーザによってキーボード入力から供給された主要資材に外部のアクセスを持っているのを含意します。 ヘッダー系列のための構文は以下の通りです。
Prearranged-Key-Info =
"Prearranged-Key-Info" ":" Hdr-Cipher "," CoveredDEK "," CoverKey-ID
CoverKey-ID = method ":" key-name
CoveredDEK = *HEX
method = "inband" | "outband"
「根回しされた主要なインフォメーションは「根回しされた主要なインフォメーション」と等しい」:、」 」 「Hdr-暗号」、CoveredDEK、」、」 CoverKey-ID CoverKey-IDがメソッドと等しい、」、:、」 主要な名前CoveredDEK=*HEXメソッドは"「不-バンド」"と等しいです。| "「外-バンド」"
While chaining ciphers require an Initialization Vector (IV) [FIPS- 81] to start off the chaining, that information is not carried by this field. Rather, it should be passed internal to the cryptographic format being used. Likewise, the bulk cipher used is specified in this fashion.
推論暗号が、初期設定Vector(IV)[FIPS81]が推論を始めるのを必要としている間、その情報はこの分野によって運ばれません。 むしろ、それは使用される暗号の形式に内部で通過されるべきです。 同様に、使用される大量の暗号はこんなやり方で指定されます。
<Hdr-Cipher> should be the name of the block cipher used to encrypt the session key (see section 3.2.4.7)
<Hdr-暗号>はセッションキーを暗号化するのに使用されるブロック暗号の名前であるべきです。(.7は、)3.2に.4を区分するのを見ます。
<CoveredDEK> is the protected Data Encryption Key (a.k.a. transaction key) under which the encapsulated message was encrypted. It should be appropriately (randomly) generated by the sending agent, then encrypted under the cover of the negotiated key (a.k.a. session key) using the indicated header cipher, and then converted into hex.
<CoveredDEK>はカプセル化されたメッセージが暗号化された保護されたデータ暗号化キー(通称トランザクションキー)です。 それは、次に交渉されたキー(通称セッションキー)のカバーの下で示されたヘッダー暗号を使用することで暗号化された送付エージェントによって適切に(手当たりしだいに)生成されて、次に、十六進法に変換されるべきです。
Rescorla & Schiffman Experimental [Page 10] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[10ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
In order to avoid name collisions, cover key namespaces must be maintained separately by host and port.
名前衝突を避けるために、ホストとポートは別々にカバーキー名前空間を維持しなければなりません。
Note that some Content-Privacy-Domains, notably likely future revisions of MOSS and CMS may have support for symmetric key management.
いくつかのContentプライバシードメインであり、モスとCMSの著しくありそうな今後の改正には対称鍵管理のサポートがあるかもしれないことに注意してください。
The Prearranged-Key-Info field need not be used in such circumstances. Rather, the native syntax is preferred. Keys exchanged with Key-Assign, however, may be used in this situation.
Prearrangedの主要なインフォメーション分野はそのような事情で使用される必要はありません。 むしろ、固有の構文は好まれます。 しかしながら、Key-案配で交換されたキーはこの状況で使用されるかもしれません。
2.4.5. MAC-Info
2.4.5. MAC-インフォメーション
This header is used to supply a Message Authenticity Check, providing
both message authentication and integrity, computed from the message
text, the time (optional -- to prevent replay attack), and a shared
secret between client and server. The MAC should be computed over the
encapsulated content of the S-HTTP message. S-HTTP/1.1 defined that
MACs should be computed using the following algorithm ('||' means
concatenation):
このヘッダーはMessage Authenticity Checkを供給するのに使用されます、通報認証とメッセージ・テキストから計算された保全の両方に時間を提供して(任意--、反射攻撃を防ぐ、)、そして、間にクライアントとサーバMACがS-HTTPメッセージのカプセル化された内容に関して計算されるべきであるという共有秘密キー。 S-HTTP/1.1は計算された使用が以下のアルゴリズム('| | '手段連結)であったならそのMACsを定義しました:
MAC = hex(H(Message||[<time>]||<shared key>))
MAC=十六進法(H(メッセージ| | [<時間>]| | <は主要な>を共有しました))
The time should be represented as an unsigned 32 bit quantity representing seconds since 00:00:00 GMT January 1, 1970 (the UNIX epoch), in network byte order. The shared key format is a local matter.
1970年1月1日(UNIX時代)グリニッジ標準時0時0分0秒以来未署名の32が秒を表す量に噛み付いたので、時間は表されるべきです、ネットワークバイトオーダーで。 共有された主要な形式は地域にかかわる事柄です。
Recent research [VANO95] has demonstrated some weaknesses in this approach, and this memo introduces a new construction, derived from [RFC-2104]. In the name of backwards compatibility, we retain the previous constructions with the same names as before. However, we also introduce a new series of names (See Section 3.2.4.8 for the names) that obey a different (hopefully stronger) construction. (^ means bitwise XOR)
最近の研究[VANO95]はこのアプローチにおけるいくつかの弱点を示しました、そして、このメモは[RFC-2104]から得られた新設を導入します。 遅れている互換性の名にかけて、私たちは従来と同様同じ名前がある前の構造を保有します。 セクション3.2を見てください。しかしながら、また、私たちが新物の名前を紹介する、(.4 .8 名前) それに関しては、異なった(願わくはより強い)構造に従ってください。 (^手段bitwise XOR)
HMAC = hex(H(K' ^ pad2 || H(K' ^ pad1 ||[<time>]|| Message)))
pad1 = the byte 0x36 repeated enough times to fill out a
hash input block. (I.e. 64 times for both MD5 and SHA-1)
pad2 = the byte 0x5c repeated enough times to fill out a
hash input block.
K' = H(<shared key>)
'HMAC=十六進法(H(K'^pad2| | H(K'^pad1| | [<時間>]| | メッセージ)))pad1=バイト0x36はハッシュ入力ブロックに書き込むことができるくらいの回を繰り返しました。 (すなわち MD5とSHA-1の両方のための64回) pad2=バイト0x5cはハッシュ入力ブロックに書き込むことができるくらいの回を繰り返しました。 'K'=H(<は主要な>を共有しました)
The original HMAC construction is for the use of a key with length equal to the length of the hash output. Although it is considered safe to use a key of a different length (Note that strength cannot be increased past the length of the hash function itself, but can be reduced by using a shorter key.) [KRAW96b] we hash the original key
オリジナルのHMAC工事はハッシュ出力の長さと等しい長さと共にキーの使用のためのものです。 それは異なった長さのキーを使用するために安全であると考えられますが(強さがハッシュ関数自体の長さの先で増強できませんが、より短いキーを使用することによって減少できることに注意してください。) [KRAW96b] 私たちはオリジナルのキーを論じ尽くします。
Rescorla & Schiffman Experimental [Page 11] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[11ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
to permit the use of shared keys (e.g. passphrases) longer than the length of the hash. It is noteworthy (though obvious) that this technique does not increase the strength of short keys.
ハッシュの長さより長い間共有されたキー(例えば、パスフレーズ)の使用を可能にするために。 それは注目に値します(明白ですが)。このテクニックは短いキーの強さを増強しません。
The format of the MAC-Info line is:
MAC-インフォメーション系列の形式は以下の通りです。
MAC-Info = "MAC-Info" ":" [hex-time], hash-alg, hex-hash-data, key-spec hex-time = <unsigned seconds since Unix epoch represented as HEX> hash-alg = <hash algorithms from section 3.2.4.8> hex-hash-data = <computation as described above represented as HEX> Key-Spec = "null" | "dek" | Key-ID
「MAC-インフォメーションは「MAC-インフォメーション」と等しい」:、」 [十六進法時間]、ハッシュ-alg、十六進法ハッシュデータ、Unix時代がHEX>としてハッシュ-algを表したので、HEX>Key-仕様が「ヌル」と等しいときに、<未署名の主要な仕様十六進法時間=秒は上で説明されるとしての.8>十六進法ハッシュデータ=<計算が表したセクション3.2.4から<ハッシュアルゴリズムと等しいです。| "dek"| 主要なID
Key-Ids can refer either to keys bound using the Key-Assign header line or those bound in the same fashion as the Outband method described later. The use of a 'Null' key-spec implies that a zero length key was used, and therefore that the MAC merely represents a hash of the message text and (optionally) the time. The special key-spec 'DEK' refers to the Data Exchange Key used to encrypt the following message body (it is an error to use the DEK key-spec in situations where the following message body is unencrypted).
Key-案配ヘッダー系列を使用することで主要なイドはキーバウンドについて言及できますか、またはそれらが後で説明されたOutbandメソッドと同じファッションでバウンドしています。 主要な'ヌル'の仕様の使用は、ゼロ・レングスキーが使用されて、したがって、MACが単にメッセージ・テキストと(任意に)現代のハッシュを表すのを含意します。 特別な主要な仕様'DEK'は以下のメッセージ本体を暗号化するのに使用されるData Exchange Keyについて言及します(それは以下のメッセージ本体が非暗号化される状況でDEKの主要な仕様を使用する誤りです)。
If the time is omitted from the MAC-Info line, it should simply not be included in the hash.
MAC-インフォメーション系列から時間を省略するなら、ハッシュにそれを絶対に含むべきではありません。
Note that this header line can be used to provide a more advanced equivalent of the original HTTP Basic authentication mode in that the user can be asked to provide a username and password. However, the password remains private and message integrity can be assured. Moreover, this can be accomplished without encryption of any kind.
ユーザがユーザ名とパスワードを提供するように頼むことができるので元のHTTP Basic認証モードの、より高度な同等物を提供するのにこのヘッダー系列を使用できることに注意してください。 しかしながら、パスワードは個人的に残っています、そして、メッセージの保全は保証できます。 そのうえ、どんな種類の暗号化なしでもこれを達成できます。
In addition, MAC-Info permits fast message integrity verification (at the loss of non-repudiability) for messages, provided that the participants share a key (possibly passed using Key-Assign in a previous message).
さらに、MAC-インフォメーションはメッセージのために速いメッセージの保全検証を可能にします(非repudiabilityの損失のときに)、関係者がキー(ことによると前のメッセージでKey-案配を使用することで通過される)を共有すれば。
Note that some Content-Privacy-Domains, notably likely future revisions of MOSS and CMS may have support for symmetric integrity protection The MAC-Info field need not be used in such circumstances. Rather, the native syntax is preferred. Keys exchanged with Key- Assign, however, may be used in this situation.
著しくモスとCMSの今後の改正にはMAC-インフォメーション分野がそうしなければならない左右対称の保全保護のサポートがあるかもしれない傾向があるいくつかのContentプライバシードメインがそのような事情で使用されないことに注意してください。 むしろ、固有の構文は好まれます。 しかしながら、Key案配で交換されたキーはこの状況で使用されるかもしれません。
2.5. Content
2.5. 内容
The content of the message is largely dependent upon the values of the Content-Privacy-Domain and Content-Transfer-Encoding fields.
メッセージの内容はContentプライバシードメインとContent転送コード化分野の値に主に依存しています。
Rescorla & Schiffman Experimental [Page 12] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[12ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
For a CMS message, with '8BIT' Content-Transfer-Encoding, the content should simply be the CMS message itself.
CMSメッセージのために、'8BIT'Content転送コード化で、内容は単にCMSメッセージ自体であるべきです。
If the Content-Privacy-Domain is MOSS, the content should consist of a MOSS Security Multipart as described in RFC1847.
Contentプライバシードメインがモスであるなら、内容はRFC1847で説明されるようにモスSecurity Multipartから成るべきです。
It is expected that once the privacy enhancements have been removed, the resulting (possibly protected) contents will be a normal HTTP request. Alternately, the content may be another Secure-HTTP message, in which case privacy enhancements should be unwrapped until clear content is obtained or privacy enhancements can no longer be removed. (This permits embedding of enhancements, such as sequential Signed and Enveloped enhancements.) Provided that all enhancements can be removed, the final de-enhanced content should be a valid HTTP request (or response) unless otherwise specified by the Content-Type line.
いったんプライバシー増進を取り除くと、結果として起こる(ことによると保護された)コンテンツが通常のHTTP要求になると予想されます。 交互に、内容が別のSecure-HTTPメッセージであるかもしれない、その場合、プライバシー増進は明確な内容を得ることができないか、もうプライバシー増進を取り除くことができないまで開けられるべきです。 (これは、連続したSignedやEnveloped増進などの増進が埋め込まれていることを許可します。) すべての増進を取り除くことができて、別の方法でコンテントタイプ系列で指定しない場合、最終的な反-高められた内容は有効なHTTP要求であるべきです(または、応答)。
Note that this recursive encapsulation of messages potentially permits security enhancements to be applied (or removed) for the benefit of intermediaries who may be a party to the transaction between a client and server (e.g., a proxy requiring client authentication). How such intermediaries should indicate such processing is described in Section 7.2.1.
メッセージのこの再帰的なカプセル化が、セキュリティ増進がパーティーであるかもしれない仲介者の利益のためにクライアントとサーバ(例えば、クライアント認証を必要とするプロキシ)の間のトランザクションに適用されることを(または、取り外します)潜在的に許可することに注意してください。 そのような仲介者がどうそのような処理を示すべきであるかはセクション7.2.1で説明されます。
2.6. Encapsulation Format Options
2.6. カプセル化形式オプション
2.6.1. Content-Privacy-Domain: CMS
2.6.1. 満足しているプライバシードメイン: cm
Content-Privacy-Domain 'CMS' follows the form of the CMS standard (see Appendix).
満足しているプライバシードメイン'CMS'はCMS規格のフォームに続きます(Appendixを見てください)。
Message protection may proceed on two orthogonal axes: signature and encryption. Any message may be either signed, encrypted, both, or neither. Note that the 'auth' protection mode of S-HTTP is provided independently of CMS coding via the MAC-Info header of section 2.3.6 since CMS does not support a 'KeyDigestedData' type, although it does support a 'DigestedData' type.
メッセージ保護は2本の直交した軸の上に続くかもしれません: 署名と暗号化。 両方、またはどちらもが暗号化されて、どんなメッセージにも署名されないかもしれません。 CMSが、'KeyDigestedData'がタイプであるとサポートしないのでS-HTTPの'auth'保護モードがセクション2.3.6歳のMAC-インフォメーションヘッダーを通したCMSコード化の如何にかかわらず提供されることに注意してください、'DigestedData'がタイプであるとサポートしますが。
2.6.1.1. Signature
2.6.1.1. 署名
This enhancement uses the 'SignedData' type of CMS. When digital signatures are used, an appropriate certificate may either be attached to the message (possibly along with a certificate chain) as specified in CMS or the sender may expect the recipient to obtain its certificate (and/or chain) independently. Note that an explicitly allowed instance of this is a certificate signed with the private component corresponding to the public component being attested to. This shall be referred to as a self-signed certificate. What, if any, weight to give to such a certificate is a purely local matter. In
この増進はCMSの'SignedData'タイプを使用します。デジタル署名が使用されているとき、適切な証明書がCMSの指定されるとしてのメッセージ(ことによると証明書チェーンに伴う)に添付されるかもしれませんか、または送付者は、受取人が独自に、証明書(鎖を作る)を入手すると予想するかもしれません。 この明らかに許容されたインスタンスが証明される公共のコンポーネントに対応する個人的なコンポーネントを契約された証明書であることに注意してください。 これは自己署名入りの証書と呼ばれるものとします。 何が、そのような証明書に与えるのにもしあれば重みを加えるかによる純粋にローカルの問題です。 コネ
Rescorla & Schiffman Experimental [Page 13] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[13ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
either case, a purely signed message is precisely CMS compliant.
どちらかのケースであり、純粋に署名しているメッセージは正確にCMS対応します。
2.6.1.2. Encryption
2.6.1.2. 暗号化
2.6.1.2.1. Encryption -- normal, public key
2.6.1.2.1. 暗号化--標準、公開鍵
This enhancement is performed precisely as enveloping (using either ' EnvelopedData' types) under CMS. A message encrypted in this fashion, signed or otherwise, is CMS compliant. To have a message which is both signed and encrypted, one simply creates the CMS SignedData production and encapsulates it in EnvelopedData as described in CMS.
この増進はまさにおおうとしてCMSの下で実行されます('EnvelopedData'を使用するのはタイプされます)。こんなやり方で暗号化された署名しているか、またはそうでないメッセージは、CMS対応します。 1つは、署名されて、暗号化されるメッセージを持つために、単にCMS SignedData生産を作成して、CMSで説明されるようにEnvelopedDataでそれをカプセル化します。
2.6.1.2.2. Encryption -- prearranged key
2.6.1.2.2. 暗号化--根回しされたキー
This uses the 'EncryptedData' type of CMS. In this mode, we encrypt the content using a DEK encrypted under cover of a prearranged session key (how this key may be exchanged is discussed later), with key identification information specified on one of the header lines. The IV is in the EncryptedContentInfo type of the EncryptedData element. To have a message which is both signed and encrypted, one simply creates the CMS SignedData production and encapsulates it in EncryptedData as described in CMS.
これはCMSの'EncryptedData'タイプを使用します。このモードで、私たちは、ヘッダー系列の1つで指定された根回しされたセッション主要な識別によって主要な(後でどうこのキーを交換するかもしれないかについて議論する)情報のカバーの下で暗号化されたDEKを使用することで内容を暗号化します。 IVはEncryptedData要素のEncryptedContentInfoタイプでそうです。 1つは、署名されて、暗号化されるメッセージを持つために、単にCMS SignedData生産を作成して、CMSで説明されるようにEncryptedDataでそれをカプセル化します。
2.6.2. Content-Privacy-Domain: MOSS
2.6.2. 満足しているプライバシードメイン: こけ
The body of the message should be a MIME compliant message with content type that matches the Content-Type line in the S-HTTP headers. Encrypted messages should use multipart/encrypted. Signed messages should use multipart/signed. However, since multipart/signed does not convey keying material, is is acceptable to use multipart/mixed where the first part is application/mosskey-data and the second part is multipart/mixed in order to convey certificates for use in verifying the signature.
メッセージ欄はS-HTTPヘッダにおけるコンテントタイプ系列に合っているcontent typeがあるMIME対応することのメッセージであるべきです。 暗号化メッセージは暗号化された複合/を使用するべきです。 署名しているメッセージは署名される複合/を使用するべきです。 しかしながら、署名される/は複合であるので合わせることの材料を運ばないで、ある、署名について確かめることにおける使用に証明書を伝えるために最初の部分がmosskeyアプリケーション/データであり、第二部が複合であるところに混ぜられたか、または混ぜられた複合/を使用するのにおいて、許容できます。
Implementation Note: When both encryption and signature are applied by the same agent, signature should in general be applied before encryption.
実装注意: 暗号化と署名の両方が同じエージェントによって適用されるとき、一般に、署名は暗号化の前に適用されるべきです。
2.6.3. Permitted HTTP headers
2.6.3. 受入れられたHTTPヘッダ
2.6.3.1. Overview
2.6.3.1. 概要
In general, HTTP [RFC-2616] headers should appear in the inner content (i.e. the message/http) of an S-HTTP message but should not appear in the S-HTTP message wrapper for security reasons. However, certain headers need to be visible to agents which do not have access to the encapsulated data. These headers may appear in the S-HTTP headers as well.
一般に、HTTP[RFC-2616]ヘッダーは、S-HTTPメッセージの内側の内容(すなわち、メッセージ/http)に現れるべきですが、S-HTTPメッセージラッパーでは安全保障上の理由で現れるべきではありません。 しかしながら、確信しているヘッダーは、エージェントにとって目に見える必要があります(カプセル化されたデータに近づく手段を持っていません)。 これらのヘッダーはまた、S-HTTPヘッダに現れるかもしれません。
Rescorla & Schiffman Experimental [Page 14] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[14ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
Please note that although brief descriptions of the general purposes of these headers are provided for clarity, the definitive reference is [RFC-2616].
これらのヘッダーの汎用の簡単な説明を明快に提供しますが、決定的な参照は[RFC-2616]です。
2.6.3.2. Host
2.6.3.2. ホスト
The host header specificies the internet host and port number of the resource being requested. This header should be used to disambiguate among multiple potential security contexts within which this message could be interpreted. Note that the unwrapped HTTP message will have it's own Host field (assuming it's an HTTP/1.1 message). If these fields do not match, the server should respond with a 400 status code.
要求されているリソースのインターネットホストのホストヘッダーspecificiesとポートナンバー。 このヘッダーは、複数の潜在的セキュリティでこのメッセージを解釈できた文脈のあいまいさを除くのに使用されるべきです。 開けられたHTTPメッセージにはそれがあるというメモは自己のHost分野(それを仮定するのは、HTTP/1.1メッセージである)です。 これらの分野が合っていないなら、サーバは400ステータスコードで反応するべきです。
2.6.3.3. Connection
2.6.3.3. 接続
The Connection field has precisely the same semantics in S-HTTP headers as it does in HTTP headers. This permits persistent connections to be used with S-HTTP.
Connection分野には、正確にS-HTTPヘッダにおける同じ意味論がHTTPヘッダでするようにあります。 これは、パーシステントコネクションがS-HTTPと共に使用されることを許可します。
3. Cryptographic Parameters
3. 暗号のパラメタ
3.1. Options Headers
3.1. オプションヘッダー
As described in Section 1.3.2, every S-HTTP request is (at least conceptually) preconditioned by the negotiation options provided by the potential receiver. The two primary locations for these options are
セクション1.3.2で説明されるように、あらゆるS-HTTP要求が潜在的受信機によって提供された交渉オプションであらかじめ調整されます(少なくとも概念的に)。これらのオプションのための2つのプライマリ位置がそうです。
1. In the headers of an HTTP Request/Response.
2. In the HTML which contains the anchor being dereferenced.
1. HTTP Request/応答のヘッダーで。 2. 「反-参照をつけ」られるアンカーを含むHTMLで。
There are two kinds of cryptographic options which may be provided: Negotiation options, as discussed in Section 3.2 convey a potential message recipient's cryptographic preferences. Keying options, as discussed in Section 3.3 provide keying material (or pointers to keying material) which may be of use to the sender when enhancing a message.
提供されるかもしれない2種類の暗号のオプションがあります: 交渉オプションであり、3.2はセクションで議論するように潜在的メッセージ受取人の暗号の好みを伝えます。 オプションを合わせて、セクション3.3で議論するようにメッセージを高めるとき送付者の役に立つかもしれない材料(または、材料を合わせることへの指針)を合わせながら、提供してください。
Binding cryptographic options to anchors using HTML extensions is the topic of the companion document [SHTML] and will not be treated here.
HTML拡張子を使用することで暗号のオプションをアンカーに縛るのは、仲間ドキュメント[SHTML]の話題であり、ここに扱われないでしょう。
Rescorla & Schiffman Experimental [Page 15] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[15ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
3.2. Negotiation Options
3.2. 交渉オプション
3.2.1. Negotiation Overview
3.2.1. 交渉概要
Both parties are able to express their requirements and preferences regarding what cryptographic enhancements they will permit/require the other party to provide. The appropriate option choices depend on implementation capabilities and the requirements of particular applications.
それらが、許可するか、または相手がどんな暗号の増進を提供するのを必要とするかに関して双方は彼らの要件と好みを言い表すことができます。 この適切なオプション選択は特定用途の実装能力と要件次第です。
A negotiation header is a sequence of specifications each conforming to a four-part schema detailing:
交渉ヘッダーはそれぞれ以下を詳しく述べる4部分の図式に従う仕様の系列です。
Property -- the option being negotiated, such as bulk encryption
algorithm.
特性--大量の暗号化アルゴリズムなどのように交渉されるオプション。
Value -- the value being discussed for the property, such as
DES-CBC
値--DES-CBCなどの特性のために議論する値
Direction -- the direction which is to be affected, namely:
during reception or origination (from the perspective of the
originator).
方向--影響を受けることである方向、すなわち: レセプションか創作(創始者の見解からの)の間。
Strength -- strength of preference, namely: required, optional,
refused
強さ--好みの強さ、すなわち: 必要で、任意で、拒否されています。
As an example, the header line:
例、ヘッダー系列として:
SHTTP-Symmetric-Content-Algorithms: recv-optional=DES-CBC,RC2
SHTTPの左右対称の満足しているアルゴリズム: recv任意の=DES-CBC、RC2
could be thought to say: "You are free to use DES-CBC or RC2 for bulk encryption for encrypting messages to me."
言うと思うことができました: 「あなたはメッセージを私に暗号化するための大量の暗号化に自由にDES-CBCかRC2を使用できます。」
We define new headers (to be used in the encapsulated HTTP header, not in the S-HTTP header) to permit negotiation of these matters.
私たちは、これらの件の交渉を可能にするために、新しいヘッダー(S-HTTPヘッダに使用されるのではなく、カプセル化されたHTTPヘッダに使用される)を定義します。
3.2.2. Negotiation Option Format
3.2.2. 交渉オプション形式
The general format for negotiation options is:
交渉オプションのための一般形式は以下の通りです。
Option = Field ":" Key-val ";" *(Key-val)
Key-val = Key "=" Value *("," Value)
Key = Mode"-"Action ; This is represented as one
; token without whitespace
Mode = "orig" | "recv"
Action = "optional" | "required" | "refused"
「オプションは分野と等しい」:、」 「主要なval」;、」 *(主要なval) 「主要な「=」主要なval=値*、(「」 値) 主要な=モード」、--「動作」。 これは1として表されます。 空白Mode="orig"のないトークン| "recv"動作=「任意です」。| 「必要です」。| 「拒否されます」。
Rescorla & Schiffman Experimental [Page 16] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[16ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
The <Mode> value indicates whether this <Key-val> refers to what the agent's actions are upon sending privacy enhanced messages as opposed to upon receiving them. For any given mode-action pair, the interpretation to be placed on the enhancements (<Value>s) listed is:
<Mode>価値は、それらを受けることと対照的にこの<Key-val>が、エージェントの動作が送付プライバシーに関するものであると言及するかどうかがメッセージを高めたのを示します。 どんな与えられたモード動作組においても、(<Value>s)が記載した増進に置かれるべき解釈は以下の通りです。
'recv-optional:' The agent will process the enhancement if the
other party uses it, but will also gladly process messages
without the enhancement.
'、recv任意である、: 'エージェントは、相手がそれを使用すると増進を処理しますが、また、増進なしでメッセージを喜んで処理するでしょう。
'recv-required:' The agent will not process messages without
this enhancement.
'recvに、: 'プロセスではなく、意志がこの増進なしで通信させるエージェントを必要としました。
'recv-refused:' The agent will not process messages with this
enhancement.
'recvに、プロセスメッセージではなく、この増進がある意志を: 'エージェントに拒絶しました。
'orig-optional:' When encountering an agent which refuses this
enhancement, the agent will not provide it, and when
encountering an agent which requires it, this agent will provide
it.
'、orig任意である、: 'この増進、エージェントに意志を拒絶するエージェントに遭遇するWhenがそれを提供しないで、それを必要とするエージェントに遭遇するとき、このエージェントはそれを提供するでしょう。
'orig-required:' The agent will always generate the enhancement.
'origに、: '意志がいつも増進を生成するエージェントを必要としました。
'orig-refused:' The agent will never generate the enhancement.
'origに、: '意志が決して生成しないエージェントに増進を拒絶しました。
The behavior of agents which discover that they are communicating with an incompatible agent is at the discretion of the agents. It is inappropriate to blindly persist in a behavior that is known to be unacceptable to the other party. Plausible responses include simply terminating the connection, or, in the case of a server response, returning 'Not implemented 501'.
エージェントの裁量には彼らが非互換なエージェントとコミュニケートしていると発見するエージェントの振舞いがあります。 盲目的に相手にとって容認できないのが知られている振舞いに固執するのは不適当です。 もっともらしい応答が、単に接続を終えるのを含んでいるか、またはサーバ応答の場合では、帰りは'501を実装しませんでした'。
Optional values are considered to be listed in decreasing order of preference. Agents are free to choose any member of the intersection of the optional lists (or none) however.
減少しているよく使われる順に任意の値が記載されていると考えられます。 しかしながら、エージェントは自由に任意のリスト(または、なにも)の交差点のどんなメンバーも選ぶことができます。
If any <Key-Val> is left undefined, it should be assumed to be set to the default. Any key which is specified by an agent shall override any appearance of that key in any <Key-Val> in the default for that field.
どんな<Key-ヴァルであるならも、>は未定義の状態で残されて、デフォルトに設定されると思われるべきです。 エージェントによって指定されるどんなキーもどんな<Keyでもヴァル>をその分野にデフォルトで合わせてどんなその外観もくつがえすものとします。
Rescorla & Schiffman Experimental [Page 17] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[17ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
3.2.3. Parametrization for Variable-length Key Ciphers
3.2.3. 可変長の主要な暗号のための助変数化
For ciphers with variable key lengths, values may be parametrized using the syntax <cipher>'['<length>']'
'可変キー長がある暗号において、値は、構文<暗号>('['<の長さの>']')を使用することでparametrizedされるかもしれません。
For example, 'RSA[1024]' represents a 1024 bit key for RSA. Ranges may be represented as
例えば、'RSA[1024]'は1024年のRSAに、主要なビットを表します。 範囲は表されるかもしれません。
<cipher>'['<bound1>'-'<bound2>']'
<'暗号>('['<bound1>'--'<bound2>']')
For purposes of preferences, this notation should be treated as if it read (assuming x and y are integers)
好みの目的のために、この記法はまるで読むかのように扱われるべきです。(xとyが整数であると仮定します)
<cipher>[x], <cipher>[x+1],...<cipher>[y] (if x<y)
<暗号>[x]、<暗号>[x+1]…<暗号>[y](x<yであるなら)
and
そして
<cipher>[x], <cipher>[x-1],...<cipher>[y] (if x>y)
<暗号>[x]、<暗号>[x-1]…<暗号>[y](x>yであるなら)
The special value 'inf' may be used to denote infinite length.
特別な値の'inf'は、無限の長さを指示するのに使用されるかもしれません。
Using simply <cipher> for such a cipher shall be read as the maximum range possible with the given cipher.
そのような暗号に単に<暗号>を使用するのは与えられた暗号で可能な最大範囲と読まれるものとします。
3.2.4. Negotiation Syntax
3.2.4. 交渉構文
3.2.4.1. SHTTP-Privacy-Domains
3.2.4.1. SHTTPプライバシードメイン
This header refers to the Content-Privacy-Domain type of section 2.3.1. Acceptable values are as listed there. For instance,
このヘッダーはセクション2.3.1人のContentプライバシードメインタイプについて言及します。 許容値はそこに同じくらい記載されています。 例えば
SHTTP-Privacy-Domains: orig-required=cms;
recv-optional=cms,MOSS
SHTTPプライバシードメイン: origが必要な=cm。 recv任意の=cm、こけ
would indicate that the agent always generates CMS compliant messages, but can read CMS or MOSS (or, unenhanced messages).
または、エージェントが、いつもCMSが対応するメッセージであると生成するのを示すでしょうが、CMSかモスを読むことができる、(「非-高め」られたメッセージ)
3.2.4.2. SHTTP-Certificate-Types
3.2.4.2. SHTTP証明書タイプ
This indicates what sort of Public Key certificates the agent will accept. Currently defined values are 'X.509' and 'X.509v3'.
これは、エージェントがどういうPublic Key証明書を受け入れるかを示します。 現在定義された値は、'X.509'と'X.509v3'です。
3.2.4.3. SHTTP-Key-Exchange-Algorithms
3.2.4.3. SHTTPの主要な交換アルゴリズム
This header indicates which algorithms may be used for key exchange. Defined values are 'DH', 'RSA', 'Outband' and 'Inband'. DH refers to Diffie-Hellman X9.42 style enveloping. [DH] RSA refers to RSA enveloping. Outband refers to some sort of external key agreement.
このヘッダーは、どのアルゴリズムが主要な交換に使用されるかもしれないかを示します。 定義された値は、'DH'と、'RSA'と、'Outband'と'Inband'です。 DHはディフィー-ヘルマンX9.42スタイルのおおうことについて言及します。 [DH]RSAはRSAのおおうことについて言及します。 Outbandはある種の外部の主要な協定を示します。
Rescorla & Schiffman Experimental [Page 18] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[18ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
Inband refers to section 3.3.3.1.
Inbandは.1にセクション3.3.3について言及します。
The expected common configuration of clients having no certificates and servers having certificates would look like this (in a message sent by the server):
証明書を全く持っていないクライアントと証明書を持っているサーバの予想された一般的な構成はこれ(サーバによって送られたメッセージの)に似ているでしょう:
SHTTP-Key-Exchange-Algorithms: orig-optional=Inband, DH;
recv-required=DH
SHTTPの主要な交換アルゴリズム: orig任意の=Inband、DH。 recvが必要な=DH
3.2.4.4. SHTTP-Signature-Algorithms
3.2.4.4. SHTTP署名アルゴリズム
This header indicates what Digital Signature algorithms may be used. Defined values are 'RSA' [PKCS-1] and 'NIST-DSS' [FIPS-186] Since NIST-DSS and RSA use variable length moduli the parametrization syntax of section 3.2.3 should be used. Note that a key length specification may interact with the acceptability of a given certificate, since keys (and their lengths) are specified in public- key certificates.
このヘッダーは、どんなDigital Signatureアルゴリズムが使用されるかもしれないかを示します。 NIST-DSSとRSAが可変長係数を使用するので、定義された値は、'RSA'[PKCS-1]と'NIST-DSS'[FIPS-186]です。セクション3.2.3の助変数化構文は使用されるべきです。 キー長仕様が与えられた証明書の受容性と対話するかもしれないことに注意してください、キー(そして、それらの長さ)が公共の主要な証明書で指定されるので。
3.2.4.5. SHTTP-Message-Digest-Algorithms
3.2.4.5. SHTTPメッセージダイジェストアルゴリズム
This indicates what message digest algorithms may be used. Previously defined values are 'RSA-MD2' [RFC-1319], 'RSA-MD5' [RFC- 1321], 'NIST-SHS' [FIPS-180].
これは、どんなメッセージダイジェストアルゴリズムが使用されるかもしれないかを示します。 以前定義された値は'RSA-MD2'[RFC-1319]、'RSA-MD5'[RFC1321]'NIST-SHS'[FIPS-180]です。
3.2.4.6. SHTTP-Symmetric-Content-Algorithms
3.2.4.6. SHTTPの左右対称の満足しているアルゴリズム
This header specifies the symmetric-key bulk cipher used to encrypt message content. Defined values are:
このヘッダーはメッセージ内容を暗号化するのに使用される対称鍵大量暗号を指定します。 定義された値は以下の通りです。
DES-CBC -- DES in Cipher Block Chaining (CBC) mode [FIPS-81]
DES-EDE-CBC -- 2 Key 3DES using Encrypt-Decrypt-Encrypt in outer
CBC mode
DES-EDE3-CBC -- 3 Key 3DES using Encrypt-Decrypt-Encrypt in outer
CBC mode
DESX-CBC -- RSA's DESX in CBC mode
IDEA-CBC -- IDEA in CBC mode
RC2-CBC -- RSA's RC2 in CBC mode
CDMF-CBC -- IBM's CDMF (weakened key DES) [JOHN93] in CBC mode
DES-CBC--Cipher Block Chaining(CBC)モード[FIPS-81]DES-EDE-CBCのDES--2Key 3DES使用、Encryptが解読する、暗号化、外側のCBCモードDES-EDE3-CBCで--、3Key 3DES使用、Encryptが解読する、暗号化、CBCモードによる外側のCBCモードDESX-CBC--CBCモードIDEA-CBCによるRSAのDESX--CBCモードRC2-CBCによるIDEA--CBCモードCDMF-CBCによるRSAのRC2--IBMのCDMF(主要なデスを弱めます)[JOHN93]
Since RC2 keys are variable length, the syntax of section 3.2.3 should be used.
RC2キーが可変長であるので、セクション3.2.3の構文は使用されるべきです。
Rescorla & Schiffman Experimental [Page 19] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[19ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
3.2.4.7. SHTTP-Symmetric-Header-Algorithms
3.2.4.7. SHTTPの左右対称のヘッダーアルゴリズム
This header specifies the symmetric-key cipher used to encrypt message headers.
このヘッダーはメッセージヘッダーを暗号化するのに使用される対称鍵暗号を指定します。
DES-ECB -- DES in Electronic Codebook (ECB) mode [FIPS-81] DES-EDE-ECB -- 2 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode DES-EDE3-ECB -- 3 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode DESX-ECB -- RSA's DESX in ECB mode IDEA-ECB -- IDEA RC2-ECB -- RSA's RC2 in ECB mode CDMF-ECB -- IBM's CDMF in ECB mode
DES-ECB--Electronic Codebook(ECB)モード[FIPS-81]DES-EDE-ECBにおけるDES--2Key 3DES使用、Encryptが解読する、暗号化、ECBモードDES-EDE3-ECBで--、3Key 3DES使用、Encryptが解読する、暗号化、ECBモードDESX-ECB--ECBモードIDEA-ECBにおけるRSAのDESX--IDEA RC2-ECB--ECBモードCDMF-ECBにおけるRSAのRC2--ECBモードによるIBMのCDMF
Since RC2 is variable length, the syntax of section 3.2.3 should be used.
RC2が可変長であるので、セクション3.2.3の構文は使用されるべきです。
3.2.4.8. SHTTP-MAC-Algorithms
3.2.4.8. SHTTP-MAC-アルゴリズム
This header indicates what algorithms are acceptable for use in providing a symmetric key MAC. 'RSA-MD2', 'RSA-MD5' and 'NIST-SHS' persist from S-HTTP/1.1 using the old MAC construction. The tokens ' RSA-MD2-HMAC', 'RSA-MD5-HMAC' and 'NIST-SHS-HMAC' indicate the new HMAC construction of 2.3.6 with the MD2, MD5, and SHA-1 algorithms respectively.
このヘッダーは、左右対称の主要なMACを提供することにおける使用において、どんなアルゴリズムが許容できるかを示します。 'RSA-MD2'、'RSA-MD5'、および'NIST-SHS'は、S-HTTP/1.1から古いMAC建築を使用することで固執しています。 トークンの'RSA-MD2-HMAC'、'RSA-MD5-HMAC'、および'NIST-SHS-HMAC'が2.3の新しいHMAC工事を示す、MD2、MD5、およびSHA-1アルゴリズムがある.6、それぞれ。
3.2.4.9. SHTTP-Privacy-Enhancements
3.2.4.9. SHTTPプライバシー増進
This header indicates security enhancements to apply. Possible values are 'sign', 'encrypt' and 'auth' indicating whether messages are signed, encrypted, or authenticated (i.e., provided with a MAC), respectively.
このヘッダーは、適用するためにセキュリティ増進を示します。 可能な値は'サイン'です、'''authを暗号化してください'が、メッセージが署名されるか、暗号化されるか、またはそれぞれ認証されるかを(すなわち、MACを提供します)示して。
3.2.4.10. Your-Key-Pattern
3.2.4.10. -キーで型に基づいて作ってください。
This is a generalized pattern match syntax to describe identifiers for a large number of types of keying material. The general syntax is:
これは材料を合わせる多くのタイプのために識別子について説明する一般化されたパターンマッチ構文です。 一般的な構文は以下の通りです。
Your-Key-Pattern =
"Your-Key-Pattern" ":" key-use "," pattern-info
key-use = "cover-key" | "auth-key" | "signing-key"
-キーで型に基づいて作ってください、」、」、:、」 」 「主要な使用」、パターンインフォメーションの主要な使用=「カバーキー」| 「auth主要です」。| 「署名主要です」。
Rescorla & Schiffman Experimental [Page 20] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[20ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
3.2.4.10.1. Cover Key Patterns
3.2.4.10.1. 雷文をカバーしてください。
This header specifies desired values for key names used for encryption of transaction keys using the Prearranged-Key-Info syntax of section 2.3.5. The pattern-info syntax consists of a series of comma separated regular expressions. Commas should be escaped with backslashes if they appear in the regexps. The first pattern should be assumed to be the most preferred.
このヘッダーはトランザクションキーの暗号化にセクション2.3.5のPrearrangedの主要なインフォメーション構文を使用することで使用される主要な名前に目標値を指定します。 パターンインフォメーション構文は一連のコンマの切り離された正規表現から成ります。 regexpsに現れるなら、コンマバックスラッシュで逃げられるべきです。 思われるべきです最初のパターンが最も都合のよいのを。
3.2.4.10.2. Auth key patterns
3.2.4.10.2. Auth雷文
Auth-key patterns specify name forms desired for use for MAC authenticators. The pattern-info syntax consists of a series of comma separated regular expressions. Commas should be escaped with backslashes if they appear in the regexps. The first pattern should be assumed to be the most preferred.
Auth-雷文はMAC固有識別文字の使用のために望まれていた名前フォームを指定します。 パターンインフォメーション構文は一連のコンマの切り離された正規表現から成ります。 regexpsに現れるなら、コンマバックスラッシュで逃げられるべきです。 思われるべきです最初のパターンが最も都合のよいのを。
3.2.4.10.3. Signing Key Pattern
3.2.4.10.3. 雷文に署名します。
This parameter describes a pattern or patterns for what keys are acceptable for signing for the digital signature enhancement. The pattern-info syntax for signing-key is:
このパラメタは、デジタル署名増進の受取にサインするのにおいて、どんなキーが許容できるかためにパターンかパターンについて説明します。 署名キーのためのパターンインフォメーション構文は以下の通りです。
pattern-info = name-domain "," pattern-data
」 「パターンインフォメーションは名前ドメインと等しい」パターンデータ
The only currently defined name-domain is 'DN-1779'. This parameter specifies desired values for fields of Distinguished Names. DNs are considered to be represented as specified in RFC1779, the order of fields and whitespace between fields is not significant.
唯一の現在定義された名前ドメインが'DN-1779'です。 このパラメタはDistinguished Namesの分野に目標値を指定します。 RFC1779で指定されるようにDNsが表されると考えられて、分野の間の分野と空白の注文は重要ではありません。
All RFC1779 values should use ',' as a separator rather than ';', since ';' is used as a statement separator in S-HTTP.
'';'以来の';'よりむしろ分離符が声明分離符としてS-HTTPに使用されるので'RFC1779値が使用するべきであるすべて'。
Pattern-data is a modified RFC1779 string, with regular expressions permitted as field values. Pattern match is performed field-wise, unspecified fields match any value (and therefore leaving the DN- Pattern entirely unspecified allows for any DN). Certificate chains may be matched as well (to allow for certificates without name subordination). DN chains are considered to be ordered left-to-right with the issuer of a given certificate on its immediate right, although issuers need not be specified. A trailing '.' indicates that the sequence of DNs is absolute. I.e. that the one furthest to the right is a root.
パターンデータは正規表現が分野値として受入れられている変更されたRFC1779ストリングです。 パターンマッチはさばき的に実行されて、不特定の分野はどんな値にも合っています(したがって、DNパターンを完全に不特定のままにすると、どんなDNも考慮されます)。 また(名前従属なしで証明書を考慮する)、証明書チェーンは合わせられるかもしれません。 即座の右の与えられた証明書の発行人と共に右に残されるようDNチェーンが命令されると考えられます、発行人は指定される必要はありませんが。 'Aの引きずる''DNsの系列が絶対であるのを示します。 すなわち、それ、もの、右に最も遠いのは、根です。
Rescorla & Schiffman Experimental [Page 21] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[21ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
The syntax for the pattern values is,
パターン値のための構文はそうです。
Value = DN-spec *("," Dn-spec)["."]
Dn-spec = "/" *(Field-spec) "/"
Field-spec := Attr = "Pattern"
Attr = "CN" | "L" | "ST" | "O" |
"OU" | "C" | <or as appropriate>
Pattern = <POSIX 1003.2 regular expressions>
「値がDN-仕様*と等しい、(「」 Dn-仕様、)、[「.」、]、「パターン」」 Dn-仕様=」 /」 *(分野仕様)」 /分野仕様:=Attr=Attrは"CN"と等しいです。| 「L」| "ST"| 「○」| "OU"| 「C」| <か適切な>として、Patternは<POSIX1003.2正規表現>と等しいです。
For example, to request that the other agent sign with a key certified by the RSA Persona CA (which uses name subordination) one could use the expression below. Note the use of RFC1779 quoting to protect the comma (an RFC1779 field separator) and the POSIX 1003.2 quoting to protect the dot (a regular expression metacharacter).
例えば、それを要求するために、キーがRSA Personaカリフォルニア(名前従属を使用する)ものによって公認されているもう片方のエージェントサインは以下の式を使用するかもしれません。 RFC1779引用の使用に注意して、コンマ(RFC1779フィールド分離)とPOSIXを保護してください、1003.2が引用される、ドット(正規表現メタキャラクタ)を保護するために。
Your-Key-Pattern: signing-key, DN-1779,
/OU=Persona Certificate, O="RSA Data Security,
Inc\."/
-キーで型に基づいて作ってください、: 署名キー、DN-1779、/OUが人格Certificateと等しく、Oが「RSA Data Security、Inc\」と等しい、/
3.2.4.11. Example
3.2.4.11. 例
A representative header block for a server follows.
サーバのための代表しているヘッダーブロックは従います。
SHTTP-Privacy-Domains: recv-optional=MOSS, CMS;
orig-required=CMS
SHTTP-Certificate-Types: recv-optional=X.509;
orig-required=X.509
SHTTP-Key-Exchange-Algorithms: recv-required=DH;
orig-optional=Inband,DH
SHTTP-Signature-Algorithms: orig-required=NIST-DSS;
recv-required=NIST-DSS
SHTTP-Privacy-Enhancements: orig-required=sign;
orig-optional=encrypt
SHTTPプライバシードメイン: recv任意の=こけ、cm。 origが必要な=cm SHTTP証明書タイプ: recv任意の=X.509。 orig必要な=X.509 SHTTP主要な交換のアルゴリズム: recvが必要な=DH。 orig任意の=Inband、DH SHTTP署名アルゴリズム: origが必要な=NIST-DSS。 必要な=NISTをrecvしているDSSのSHTTPプライバシー増進: origが必要な=サイン。 origに任意の=は暗号化します。
3.2.4.12. Defaults
3.2.4.12. デフォルト
Explicit negotiation parameters take precedence over default values. For a given negotiation option type, defaults for a given mode-action pair (such as 'orig-required') are implicitly merged unless explicitly overridden.
明白な交渉パラメタはデフォルト値の上で優先します。 与えられた交渉オプションタイプにおいて、明らかにくつがえされない場合、与えられたモード動作組('origが必要である'ように)デフォルトはそれとなく合併されています。
The default values (these may be negotiated downward or upward) are:
デフォルト値(これらは下向きか上向きに交渉されるかもしれない)は以下の通りです。
SHTTP-Privacy-Domains: orig-optional=CMS;
recv-optional=CMS
SHTTP-Certificate-Types: orig-optional=X.509;
recv-optional=X.509
SHTTP-Key-Exchange-Algorithms: orig-optional=DH,Inband,Outband;
SHTTPプライバシードメイン: orig任意の=cm。 recv任意の=cm SHTTP証明書タイプ: orig任意の=X.509。 recv任意の=X.509 SHTTP主要な交換のアルゴリズム: orig任意の=DH、Inband、Outband。
Rescorla & Schiffman Experimental [Page 22] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[22ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
recv-optional=DH,Inband,Outband
SHTTP-Signature-Algorithms: orig-optional=NIST-DSS;
recv-optional=NIST-DSS
SHTTP-Message-Digest-Algorithms: orig-optional=RSA-MD5;
recv-optional=RSA-MD5
SHTTP-Symmetric-Content-Algorithms: orig-optional=DES-CBC;
recv-optional=DES-CBC
SHTTP-Symmetric-Header-Algorithms: orig-optional=DES-ECB;
recv-optional=DES-ECB
SHTTP-Privacy-Enhancements: orig-optional=sign,encrypt, auth;
recv-required=encrypt;
recv-optional=sign, auth
3.3. Non-Negotiation Headers
recv任意の=DH、Inband、Outband SHTTP署名アルゴリズム: orig任意の=NIST-DSS。 任意の=NISTをrecvしているDSSのSHTTPメッセージダイジェストアルゴリズム: orig任意の=RSA-MD5。 recv任意の=RSA-MD5 SHTTP左右対称の内容のアルゴリズム: orig任意の=DES-CBC。 recv任意の=デス-CBC SHTTP左右対称のヘッダーアルゴリズム: orig任意の=DES-ECB。 任意の=デス-ECBをrecvしているSHTTPプライバシー増進: orig任意の=サイン、authに、暗号化します。 recvに必要な=が暗号化する、。 recv任意の=サイン、auth3.3。 譲渡禁止ヘッダー
There are a number of options that are used to communicate or identify the potential recipient's keying material.
材料を合わせる潜在的受取人のものをコミュニケートするか、または特定するのに使用される多くのオプションがあります。
3.3.1. Encryption-Identity
3.3.1. 暗号化アイデンティティ
This header identifies a potential principal for whom the message described by these options could be encrypted; Note that this explicitly permits return encryption under (say) public key without the other agent signing first (or under a different key than that of the signature). The syntax of the Encryption-Identity line is:
このヘッダーはこれらのオプションで説明されたメッセージを暗号化できた潜在的元本を特定します。 これが最初にもう片方のエージェント署名なしで(言います)公開鍵の下でリターン暗号化を明らかに可能にすることに注意してください、(異なったキー、署名のもの) Encryption-アイデンティティ系列の構文は以下の通りです。
Encryption-Identity =
"Encryption Identity" ":" name-class,key-sel,name-arg
name-class = "DN-1779" | MOSS name forms
「暗号化アイデンティティは「暗号化のアイデンティティ」と等しい」:、」 名前クラス、主要なsel、名前-arg名前クラス="DN-1779"| モスはフォームを命名します。
The name-class is an ASCII string representing the domain within which the name is to be interpreted, in the spirit of MOSS. In addition to the MOSS name forms of RFC1848, we add the DN-1779 name form to represent a more convenient form of distinguished name.
名前クラスは解釈される名前がことであるドメインを表すASCIIストリングです、モスの精神で。 形成というモス名(RFC1848)に加えて、私たちは、より便利なフォームの分類名を表すために形成というDN-1779名を加えます。
3.3.1.1. DN-1779 Name Class
3.3.1.1. DN-1779名前のクラス
The argument is an RFC-1779 encoded DN.
議論はRFC-1779がDNをコード化したということです。
3.3.2. Certificate-Info
3.3.2. 証明書インフォメーション
In order to permit public key operations on DNs specified by Encryption-Identity headers without explicit certificate fetches by the receiver, the sender may include certification information in the Certificate-Info option. The format of this option is:
受信機によって明白な証明書フェッチなしでEncryption-アイデンティティヘッダーによって指定されたDNsで公開鍵操作を可能にするために、送付者はCertificate-インフォメーションオプションで証明情報を入れるかもしれません。 このオプションの形式は以下の通りです。
Certificate-Info: <Cert-Fmt>','<Cert-Group>
証明書インフォメーション: <'本命、-、Fmt>、''<本命グループ>'
<Cert-Fmt> should be the type of <Cert-Group> being presented.
<本命、-Fmt>は寄贈される<Cert-グループ>のタイプであるべきです。
Rescorla & Schiffman Experimental [Page 23] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[23ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
Defined values are 'PEM' and 'CMS'. CMS certificate groups are provided as a base-64 encoded CMS SignedData message containing sequences of certificates with or without the SignerInfo field. A PEM format certificate group is a list of comma-separated base64-encoded PEM certificates.
定義された値は、'PEM'と'CMS'です。 SignerInfo分野のあるなしにかかわらず証明書の系列を含むベース-64のコード化されたCMS SignedDataメッセージとしてCMS証明書グループを提供します。 PEM形式証明書グループはコンマで切り離されたbase64によってコード化されたPEM証明書のリストです。
Multiple Certificate-Info lines may be defined.
複数のCertificate-インフォメーション系列が定義されるかもしれません。
3.3.3. Key-Assign
3.3.3. キーアサイン
This option serves to indicate that the agent wishes to bind a key to a symbolic name for (presumably) later reference.
このオプションは、エージェントが(おそらく)後の参照で英字名のキーを縛りたがっているのを示すのに役立ちます。
The general syntax of the key-assign header is:
キーアサインヘッダーの一般的な構文は以下の通りです。
Key-Assign =
"Key-Assign" ":" Method "," Key-Name ","
Lifetime "," Ciphers ";" Method-args
「キーアサインは「キーアサイン」と等しい」:、」 」 「メソッド」、主要な名前、」、」 生涯、」、」 暗号、」、;、」 メソッド-args
Key-name = string
Lifetime = "this" | "reply" | ""
Method ="inband"
Ciphers = "null" | Cipher+
Cipher" = <Header cipher from section 3.2.4.7>
kv = "4" | "5"
主要な名前=ストリングLifetimeは「これ」と等しいです。| 「返答してください」| 「「メソッド="「不-バンド」"暗号は「ヌル」と等しいです」。| 「暗号+暗号」はセクション3.2.4からの<Header暗号と.7>kv=「4インチ」等しいです。| "5"
Key-Name is the symbolic name to which this key is to be bound. Ciphers is a list of ciphers for which this key is potentially applicable (see the list of header ciphers in section 3.2.4.7). The keyword 'null' should be used to indicate that it is inappropriate for use with ANY cipher. This is potentially useful for exchanging keys for MAC computation.
主要な名前はこのキーによって制限されていることになっている英字名です。 暗号はこのキーが潜在的に適切である暗号のリスト(ヘッダーのリストがセクション3.2.4で.7を解くのを確実にする)です。 'ヌル'というキーワードは、使用に、それがどんな暗号によっても不適当であることを示すのに使用されるべきです。 これは潜在的にMAC計算のためのキーを交換することの役に立ちます。
Lifetime is a representation of the longest period of time during which the recipient of this message can expect the sender to accept that key. 'this' indicates that it is likely to be valid only for reading this transmission. 'reply' indicates that it is useful for a reply to this message. If a Key-Assign with the reply lifetime appears in a CRYPTOPTS block, it indicates that it is good for at least one (but perhaps only one) dereference of this anchor. An unspecified lifetime implies that this key may be reused for an indefinite number of transactions.
寿命はこのメッセージの受取人が、送付者が、それが主要であると受け入れると予想できる最も長い期間の表現です。 'これ'は、それが単にこのトランスミッションを読むのに有効である傾向があることを示します。 '回答'は、それがこのメッセージに関する回答の役に立つのを示します。 Key-案配である、回答、生涯、あるCRYPTOPTSブロック、それが示すコネにこのアンカーの少なくとも1つ(しかし、恐らく1つだけ)の反参照に良い状態で見えます。 不特定の寿命は、このキーが無期数のトランザクションのために再利用されるかもしれないのを含意します。
Method should be one of a number of key exchange methods. The only currently defined value is 'inband' referring to Inband keys (i.e., direct assignment).
メソッドは多くの主要な交換メソッドの1つであるべきです。 唯一の現在定義された値がInbandキー(すなわち、ダイレクト課題)について言及する'「不-バンド」'です。
Rescorla & Schiffman Experimental [Page 24] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[24ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
This header line may appear either in an unencapsulated header or in an encapsulated message, though when an uncovered key is being directly assigned, it may only appear in an encrypted encapsulated content. Assigning to a key that already exists causes that key to be overwritten.
このヘッダー系列は非カプセル化されたヘッダーかカプセル化されたメッセージに現れるかもしれません、むき出しのキーが直接割り当てられているときだけ、暗号化されたカプセル化された内容に現れるかもしれませんが。 既に存在するキーへの割り当てはそのキーを上書きさせます。
Keys defined by this header are referred to elsewhere in this specification as Key-IDs, which have the syntax:
このヘッダーによって定義されたキーはKey-IDとしてこの仕様のほかの場所と呼ばれます:(IDには、構文があります)。
Key-ID = method ":" key-name
「主要なIDはメソッドと等しい」:、」 主要な名前
3.3.3.1. Inband Key Assignment
3.3.3.1. Inbandの主要な課題
This refers to the direct assignment of an uncovered key to a symbolic name. Method-args should be just the desired session key encoded in hexidecimal as in:
これは英字名のむき出しのキーのダイレクト課題を示します。 メソッド-argsは以下のようにただhexidecimalでコード化された必要なセッションキーであるべきです。
Key-Assign: inband,akey,reply,DES-ECB;0123456789abcdef
キーアサイン: 「不-バンド」、akey、回答、DES-ECB; 0123456789abcdef
Short keys should be derived from long keys by reading bits from left to right.
長いキーから左から右までビットを読むことによって、短いキーを得るべきです。
Note that inband key assignment is especially important in order to permit confidential spontaneous communication between agents where one (but not both) of the agents have key pairs. However, this mechanism is also useful to permit key changes without public key computations. The key information is carried in this header line must be in the inner secured HTTP request, therefore use in unencrypted messages is not permitted.
「不-バンド」の主要な課題がエージェントのエージェントの(両方だけでない)が主要にする1つが対にされる秘密の自然発生的なコミュニケーションを可能にするために特に重要であることに注意してください。 しかしながら、また、このメカニズムも、公開鍵計算なしでキーチェンジを可能にするために役に立ちます。 主要な情報は運ばれて、このヘッダー系列が内側の機密保護しているHTTP要求にあるに違いなくて、したがって、非暗号化されたメッセージにおける使用が受入れられないということです。
3.3.4. Nonces
3.3.4. 一回だけ
Nonces are opaque, transient, session-oriented identifiers which may be used to provide demonstrations of freshness. Nonce values are a local matter, although they are might well be simply random numbers generated by the originator. The value is supplied simply to be returned by the recipient.
一回だけは新しさのデモンストレーションを提供するのに使用されるかもしれない不透明で、一時的で、セッション指向の識別子です。 それらはたぶん創始者によって生成された単に無作為の数であるだろうということですが、一回だけの値は地域にかかわる事柄です。 単に受取人によって返されるように、値を供給します。
3.3.4.1. Nonce
3.3.4.1. 一回だけ
This header is used by an originator to specify what value is to be returned in the reply. The field may be any value. Multiple nonces may be supplied, each to be echoed independently.
このヘッダーは、どんな値が回答で返されるかことであるかと指定するのに創始者によって使用されます。 分野はどんな値であるかもしれません。 それぞれ独自に反響されるように複数の一回だけを供給するかもしれません。
The Nonce should be returned in a Nonce-Echo header line. See section 4.1.1.
Nonce-エコーヘッダー系列でNonceを返すべきです。 セクション4.1.1を見てください。
Rescorla & Schiffman Experimental [Page 25] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[25ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
3.4. Grouping Headers With SHTTP-Cryptopts
3.4. SHTTP-Cryptoptsがあるヘッダーを分類します。
In order for servers to bind a group of headers to an HTML anchor, it is possible to combine a number of headers on a single S-HTTP Cryptopts header line. The names of the anchors to which these headers apply is indicated with a 'scope' parameter.
サーバがHTMLアンカーにヘッダーのグループを縛るように、ただ一つのS-HTTP Cryptoptsヘッダー系列の多くのヘッダーを結合するのは可能です。 これらのヘッダーが適用するアンカーの名前は'範囲'パラメタで示されます。
3.4.1. SHTTP-Cryptopts
3.4.1. SHTTP-Cryptopts
This option provides a set of cryptopts and a list of references to which it applies. (For HTML, these references would be named using the NAME tag). The names are provided in the scope attribute as a comma separated list and separated from the next header line by a semicolon. The format for the SHTTP-Cryptopts line is:
このオプションはcryptoptsの1セットとそれが適用される参考文献一覧を提供します。 (HTMLにちなんで、これらの参照はNAMEタグを使用すると命名されるでしょう。) 名前は、コンマの切り離されたリストとして有効範囲属性に提供されて、セミコロンによって次のヘッダー系列と切り離されます。 SHTTP-Cryptopts系列のための形式は以下の通りです。
SHTTP-Cryptopts =
"SHTTP-Cryptopts" ":" scope ";" cryptopt-list
scope = "scope="<tag-spec> ; This is all one token without whitespace
tag-spec = tag *("," tag) | ""
cryptopt-list = cryptopt *(";" cryptopt)
cryptopt = <S-HTTP cryptopt lines described below>
tag = <value used in HTML anchor NAME attribute>
「SHTTP-Cryptoptsは「SHTTP-Cryptopts」と等しい」:、」 「範囲」;、」 cryptopt-リスト範囲が等しい、「範囲は「仕様にタグ付けををしている<>」と等しいです。 これが空白タグ仕様のないすべての1つのトークン=タグ*である、(「」、タグ)| 「「cryptopt-リスト=cryptopt*、(「」、;、<S-HTTP cryptopt cryptopt) cryptopt=系列が>タグ=の下で値がHTMLアンカー名前属性>で使用した<について説明した 」
For example:
例えば:
SHTTP-Cryptopts: scope=tag1,tag2;
SHTTP-Privacy-Domains:
orig-required=cms; recv-optional=cms,MOSS
SHTTP-Cryptopts: 範囲はtag1、tag2と等しいです。 SHTTPプライバシードメイン: origが必要な=cm。 recv任意の=cm、こけ
If a message contains both S-HTTP negotiation headers and headers grouped on SHTTP-Cryptopts line(s), the other headers shall be taken to apply to all anchors not bound on the SHTTP-Cryptopts line(s). Note that this is an all-or-nothing proposition. That is, if a SHTTP-Cryptopts header binds options to a reference, then none of these global options apply, even if some of the options headers do not appear in the bound options. Rather, the S-HTTP defaults found in Section 3.2.4.11 apply.
メッセージがS-HTTP交渉ヘッダーとSHTTP-Cryptopts系列で分類されたヘッダーの両方を含んでいるなら、他のヘッダーは、SHTTP-Cryptopts系列で縛られたというわけではないすべてのアンカーに適用するために連れて行かれるものとします。 注意、オール、無、提案。 すなわち、SHTTP-Cryptoptsヘッダーが参照にオプションを縛るなら、これらのグローバルなオプションのいずれも適用されません、何人かのオプションヘッダーが制限されたオプションに現れないでも。 むしろ、S-HTTPデフォルトによって、セクション3.2.4で.11が適用されるのがわかりました。
4. New Header Lines for HTTP
4. HTTPのための新しいヘッダー線
Two non-negotiation header lines for HTTP are defined here.
HTTPのための2つの譲渡禁止ヘッダー系列がここで定義されます。
4.1. Security-Scheme
4.1. セキュリティ体系
All S-HTTP compliant agents must generate the Security-Scheme header in the headers of all HTTP messages they generate. This header permits other agents to detect that they are communicating with an S-HTTP compliant agent and generate the appropriate cryptographic
すべてのS-HTTP対応することのエージェントがそれらが生成するすべてのHTTPメッセージのヘッダーでSecurity-体系ヘッダーを生成しなければなりません。 このヘッダーが彼らがS-HTTP対応することのエージェントとコミュニケートしていて、好個を生成する検出する他のエージェントを可能にする、暗号
Rescorla & Schiffman Experimental [Page 26] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[26ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
options headers.
オプションヘッダー。
For implementations compliant with this specification, the value must be 'S-HTTP/1.4'.
'値がこの仕様による対応することの実装のための、そうでなければならない、-、HTTP、/、1.4'
4.1.1. Nonce-Echo
4.1.1. 一回だけのエコー
The header is used to return the value provided in a previously received Nonce: field. This has to go in the encapsulated headers so that it an be cryptographically protected.
ヘッダーは以前に容認されたNonceに提供された値を返すのに使用されます: さばきます。 これにはそうが順調なコネへのカプセル化されたヘッダーのためにある、それ、それ、暗号で保護されてください。
5. (Retriable) Server Status Error Reports
5. (Retriable) サーバ状態エラー・レポート
We describe here the special processing appropriate for client retries in the face of servers returning an error status.
私たちは、サーバに直面してエラー状況を返しながら、ここでクライアント再試行に、適切な特別な処理について説明します。
5.1. Retry for Option (Re)Negotiation
5.1. オプション(re)交渉には、再試行してください。
A server may respond to a client request with an error code that indicates that the request has not completely failed but rather that the client may possibly achieve satisfaction through another request. HTTP already has this concept with the 3XX redirection codes.
サーバは要求が完全に失敗するというわけではありませんでしたが、むしろ、クライアントがことによると別の要求で満足を達成するかもしれないのを示すエラーコードでクライアント要求に応じるかもしれません。 HTTPには、3XXリダイレクションコードがあるこの概念が既にあります。
In the case of S-HTTP, it is conceivable (and indeed likely) that the server expects the client to retry his request using another set of cryptographic options. E.g., the document which contains the anchor that the client is dereferencing is old and did not require digital signature for the request in question, but the server now has a policy requiring signature for dereferencing this URL. These options should be carried in the header of the encapsulated HTTP message, precisely as client options are carried.
S-HTTPの場合では、サーバが、クライアントが彼の要求を再試行するともう1セットの暗号のオプションを使用することで予想するのは、想像できて(本当にありそう。)です。 例えば、クライアントが「反-参照をつけ」ているアンカーを含むドキュメントは、古く、問題の要求のためのデジタル署名を必要としませんでしたが、サーバには、現在、このURLに「反-参照をつけ」るための署名を必要とする方針があります。 まさにクライアントオプションが運ばれるようにこれらのオプションはカプセル化されたHTTPメッセージのヘッダーで運ばれるべきです。
The general idea is that the client will perform the retry in the manner indicated by the combination of the original request and the precise nature of the error and the cryptographic enhancements depending on the options carried in the server response.
概念はクライアントがオリジナルの要求と誤りの正確な本質とサーバ応答で運ばれたオプションによる暗号の増進の組み合わせで示された方法で再試行を実行するということです。
The guiding principle in client response to these errors should be to provide the user with the same sort of informed choice with regard to dereference of these anchors as with normal anchor dereference. For instance, in the case above, it would be inappropriate for the client to sign the request without requesting permission for the action.
これらの誤りへのクライアント応答における指導原理は正常なアンカー反参照ならこれらのアンカーの反参照に関して同じ種類のインフォームド・チョイスをユーザに提供することであるべきです。 例えば、場合では、上では、クライアントが動作のために許可を要求しないで要求に署名するのが、不適当でしょう。
Rescorla & Schiffman Experimental [Page 27] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[27ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
5.2. Specific Retry Behavior
5.2. 特定の再試行の振舞い
5.2.1. Unauthorized 401, PaymentRequired 402
5.2.1. 権限のない401、PaymentRequired402
The HTTP errors 'Unauthorized 401', 'PaymentRequired 402' represent failures of HTTP style authentication and payment schemes. While S- HTTP has no explicit support for these mechanisms, they can be performed under S-HTTP while taking advantage of the privacy services offered by S-HTTP. (There are other errors for S-HTTP specific authentication errors.)
HTTP誤り'権限のない401'、'PaymentRequired402'はHTTPスタイル認証と支払い体系の失敗を表します。 S HTTPにはこれらのメカニズムのどんな明白なサポートもない間、S-HTTPによって提供されたプライバシーサービスを利用している間、S-HTTPの下でそれらを実行できます。 (S-HTTPの特定の認証誤りのための他の誤りがあります。)
5.2.2. 420 SecurityRetry
5.2.2. 420 SecurityRetry
This server status reply is provided so that the server may inform the client that although the current request is rejected, a retried request with different cryptographic enhancements is worth attempting. This header shall also be used in the case where an HTTP request has been made but an S-HTTP request should have been made. Obviously, this serves no useful purpose other than signalling an error if the original request should have been encrypted, but in other situations (e.g. access control) may be useful.
サーバが、現在の要求が拒絶されますが、異なった暗号の増進による再試行された要求は試みる価値があることをクライアントに知らせることができるように、このサーバ状態回答を提供します。 また、このヘッダーはHTTP要求をしましたが、S-HTTP要求をするべきであった場合に使用されるものとします。 明らかに、これは、オリジナルの要求が暗号化されるべきであったなら誤りに合図するのを除いたどんな役に立つ目的にも役立ちませんが、他の状況(例えば、アクセスコントロール)で役に立つかもしれません。
5.2.2.1. SecurityRetries for S-HTTP Requests
5.2.2.1. S-HTTP要求のためのSecurityRetries
In the case of a request that was made as an SHTTP request, it indicates that for some reason the cryptographic enhancements applied to the request were unsatisfactory and that the request should be repeated with the options found in the response header. Note that this can be used as a way to force a new public key negotiation if the session key in use has expired or to supply a unique nonce for the purposes of ensuring request freshness.
SHTTP要求としてされた要求の場合では、それは、ある理由で要求に適用された暗号の増進が不十分であり、オプションが応答ヘッダで見つけられている状態で要求が繰り返されるべきであるのを示します。 主要な使用でセッションが期限が切れたなら新しい公開鍵交渉を強制する方法としてこれを使用できることに注意するか、またはユニークな一回だけを確実にすることの目的に供給するために、新しさを要求してください。
5.2.2.2. SecurityRetries for HTTP Requests
5.2.2.2. HTTP要求のためのSecurityRetries
If the 420 code is returned in response to an HTTP request, it indicates that the request should be retried using S-HTTP and the cryptographic options indicated in the response header.
420コードがHTTP要求に対応して返されるなら、それは、要求がS-HTTPと応答ヘッダで示された暗号のオプションを使用することで再試行されるべきであるのを示します。
5.2.3. 421 BogusHeader
5.2.3. 421 BogusHeader
This error code indicates that something about the S-HTTP request was bad. The error code is to be followed by an appropriate explanation, e.g.:
このエラーコードは、S-HTTP要求に関するものが何か悪かったのを示します。 エラーコードは適切な説明が例えばあとに続くことです:
421 BogusHeader Content-Privacy-Domain must be specified
421BogusHeader Contentプライバシードメインを指定しなければなりません。
Rescorla & Schiffman Experimental [Page 28] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[28ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
5.2.4. 422 SHTTP Proxy Authentication Required
5.2.4. 422 SHTTPプロキシ認証が必要です。
This response is analagous to the 420 response except that the options in the message refer to enhancements that the client must perform in order to satisfy the proxy.
メッセージにおけるオプションがクライアントがプロキシを満たすために実行しなければならない増進について言及するのを除いて、この応答は420応答へのanalagousです。
5.2.5. 320 SHTTP Not Modifed
5.2.5. 320 Modifedではなく、SHTTP
This response code is specifically for use with proxy-server interaction where the proxy has placed the If-Modified-Since header in the S-HTTP headers of its request. This response indicates that the following S-HTTP message contains sufficient keying material for the proxy to forward the cached document for the new requestor.
この応答コードは特に使用のためにプロキシが以来変更されたIfヘッダーを要求のS-HTTPヘッダに任命したところにプロキシサーバ相互作用をもってあります。 この応答は、以下のS-HTTPメッセージがプロキシが新しい要請者へのキャッシュされたドキュメントを転送できるくらいの合わせることの材料を含むのを示します。
In general, this takes the form of an S-HTTP message where the actual enhanced content is missing, but all the headers and keying material are retained. (I.e. the optional content section of the CMS message has been removed.) So, if the original response was encrypted, the response contains the original DEK re-covered for the new recipient. (Notice that the server performs the same processing as it would have in the server side caching case of 7.1 except that the message body is elided.)
一般に、これは実際の高められた内容がなくなりますが、すべてのヘッダーと材料を合わせるのが保有されるS-HTTPメッセージの形を取ります。 (すなわち、CMSメッセージの任意の満足しているセクションは取り外されました。) それで、オリジナルの応答が暗号化されたなら、応答は新しい受取人のために再びおおわれたオリジナルのDEKを含んでいます。 (サーバがメッセージ本体が削除されるのを除いて、側はそれでサーバで7.1に関するケースをキャッシュするでしょう、したがって、処理しながら同じくらい実行するのに注意してください。)
5.2.6. Redirection 3XX
5.2.6. リダイレクション3XX
These headers are again internal to HTTP, but may contain S-HTTP negotiation options of significance to S-HTTP. The request should be redirected in the sense of HTTP, with appropriate cryptographic precautions being observed.
これらのヘッダーは、再び、HTTPに内部ですが、意味のS-HTTP交渉オプションをS-HTTPに含むかもしれません。 適切な暗号の注意が守られる状態で、要求はHTTPの意味で向け直されるべきです。
5.3. Limitations On Automatic Retries
5.3. 自動再試行の制限
Permitting automatic client retry in response to this sort of server response permits several forms of attack. Consider for the moment the simple credit card case:
この種類のサーバ応答に対応して自動クライアント再試行を可能にすると、いくつかの形式の攻撃は可能にします。 さしあたり、シンプル・クレジットカードケースを考えてください:
The user views a document which requires his credit card. The
user verifies that the DN of the intended recipient is acceptable
and that the request will be encrypted and dereferences the
anchor. The attacker intercepts the server's reply and responds
with a message encrypted under the client's public key containing
the Moved 301 header. If the client were to automatically perform
this redirect it would allow compromise of the user's credit
card.
ユーザは彼のクレジットカードを必要とするドキュメントを見ます。 ユーザは要求が意図している受取人のDNが許容できて、暗号化されていてアンカーの反参照になることを確かめます。 攻撃者は、サーバの回答を妨害して、メッセージがMovedを含むクライアントの公開鍵の下で暗号化されている状態で、301ヘッダーを反応させます。 クライアントが自動的に再直接でこれを実行するなら、それはユーザのクレジットカードの感染を許容するでしょうに。
Rescorla & Schiffman Experimental [Page 29] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[29ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
5.3.1. Automatic Encryption Retry
5.3.1. 自動暗号化再試行
This shows one possible danger of automatic retries -- potential compromise of encrypted information. While it is impossible to consider all possible cases, clients should never automatically reencrypt data unless the server requesting the retry proves that he already has the data. So, situations in which it would be acceptable to reencrypt would be if:
これは自動再試行という1つの可能な危険を示しています--暗号化された情報の潜在的感染。 すべての可能なケースを考えるのが不可能である間、再試行を要求するサーバが、彼にはデータが既にあると立証しない場合、クライアントは自動的にデータを決して再暗号化するべきではありません。 それで、それがreencryptに許容できる状況がそうであるだろう、:
1. The retry response was returned encrypted under an inband key
freshly generated for the original request.
2. The retry response was signed by the intended recipient of the
original request.
3. The original request used an outband key and the response is
encrypted under that key.
1. オリジナルの要求のために新たに生成された「不-バンド」キーの下で暗号化されていた状態で再試行応答を返しました。 2. 再試行応答はオリジナルの要求の意図している受取人によって署名されました。 3. オリジナルの要求は「外-バンド」キーを使用しました、そして、応答はそのキーの下で暗号化されます。
This is not an exhaustive list, however the browser author would be well advised to consider carefully before implementing automatic reencryption in other cases. Note that an appropriate behavior in cases where automatic reencryption is not appropriate is to query the user for permission.
これが完全なりストでない、しかしながら、他の場合で自動「再-暗号化」を実装する前にブラウザ作者が熟考するように上手にアドバイスされるでしょう。 自動「再-暗号化」が適切でない場合における適切な行動が許可のためにユーザについて質問することであることに注意してください。
5.3.2. Automatic Signature Retry
5.3.2. 自動署名再試行
Since we discourage automatic (without user confirmation) signing in even the usual case, and given the dangers described above, it is prohibited to automatically retry signature enchancement.
私たちが普通の場合さえにおける自動(ユーザ確認のない)である署名に水をさしていて、上で説明された危険を考えて、それは、自動的に署名enchancementを再試行するために禁止されています。
5.3.3. Automatic MAC Authentication Retry
5.3.3. 自動MAC認証再試行
Assuming that all the other conditions are followed, it is permissible to automatically retry MAC authentication.
他のすべての状態が続かれていると仮定して、自動的にMAC認証を再試行するのは許されています。
6. Other Issues
6. 他の問題
6.1. Compatibility of Servers with Old Clients
6.1. 年取ったクライアントとのサーバの互換性
Servers which receive requests in the clear which should be secured should return 'SecurityRetry 420' with header lines set to indicate the required privacy enhancements.
機密保護されるべきである明確に要求を受け取るサーバは必要なプライバシー増進を示すように設定されたヘッダー系列がある'SecurityRetry420'を返すべきです。
6.2. URL Protocol Type
6.2. URLプロトコルタイプ
We define a new URL protocol designator, 'shttp'. Use of this designator as part of an anchor URL implies that the target server is S-HTTP capable, and that a dereference of this URL should undergo S- HTTP processing.
私たちは新しいURLプロトコル指示子、'shttp'を定義します。 1つのアンカーURLの一部としてのこの指示子の使用は、目標サーバができるS-HTTPであり、このURLの反参照がS HTTP処理を受けるはずであるのを含意します。
Rescorla & Schiffman Experimental [Page 30] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[30ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
Note that S-HTTP oblivious agents should not be willing to dereference a URL with an unknown protocol specifier, and hence sensitive data will not be accidentally sent in the clear by users of non-secure clients.
S-HTTPの忘れっぽいエージェントが未知のプロトコル特許説明書の作成書の、そして、したがって、機密のデータがあるURLが非安全なクライアントのユーザによる明確で偶然送られない反参照に望むべきでないことに注意してください。
6.3. Browser Presentation
6.3. ブラウザプレゼンテーション
6.3.1. Transaction Security Status
6.3.1. トランザクションセキュリティ状態
While preparing a secure message, the browser should provide a visual indication of the security of the transaction, as well as an indication of the party who will be able to read the message. While reading a signed and/or enveloped message, the browser should indicate this and (if applicable) the identity of the signer. Self- signed certificates should be clearly differentiated from those validated by a certification hierarchy.
安全なメッセージを準備している間、ブラウザはトランザクションのセキュリティの視覚しるしを供給するべきです、メッセージを読むことができるパーティーのしるしと同様に。 署名しているそして/または、おおわれたメッセージを読んでいる間、ブラウザはこれと署名者の(適切であるなら)アイデンティティを示すべきです。 証明書であると署名される自己は証明階層構造によって有効にされたものと明確に区別されるべきです。
6.3.2. Failure Reporting
6.3.2. 失敗報告
Failure to authenticate or decrypt an S-HTTP message should be presented differently from a failure to retrieve the document. Compliant clients may at their option display unverifiable documents but must clearly indicate that they were unverifiable in a way clearly distinct from the manner in which they display documents which possessed no digital signatures or documents with verifiable signatures.
S-HTTPメッセージを認証するか、または解読しない場合、ドキュメントを検索しないことと異なって提示されるべきです。 言いなりになっているクライアントは、彼らの選択のときに立証不可能なドキュメントを表示するかもしれませんが、それらが彼らが証明可能な署名と共にデジタル署名を全く持っていなかったドキュメントかドキュメントを表示する方法と明確に異なった方法で立証不可能であったのを明確に示さなければなりません。
6.3.3. Certificate Management
6.3.3. 証明書管理
Clients shall provide a method for determining that HTTP requests are to be signed and for determining which (assuming there are many) certificate is to be used for signature. It is suggested that users be presented with some sort of selection list from which they may choose a default. No signing should be performed without some sort of explicit user interface action, though such action may take the form of a persistent setting via a user preferences mechanism (although this is discouraged.)
クライアントはHTTP要求が署名されることであることを決定して、どの(多くがあると仮定します)証明書が署名に使用されるかことであるかを決定するためのメソッドを提供するものとします。 彼らがデフォルトを選ぶかもしれないある種の選択リストがユーザに与えられることが提案されます。 署名しないことはある種の明白なユーザーインタフェース動作なしで実行されるべきです、そのような動作がユーザー選択メカニズムで永続的な設定の形を取るかもしれませんが(これはがっかりしていますが。)
6.3.4. Anchor Dereference
6.3.4. アンカーDereference
Clients shall provide a method to display the DN and certificate chain associated with a given anchor to be dereferenced so that users may determine for whom their data is being encrypted. This should be distinct from the method for displaying who has signed the document containing the anchor since these are orthogonal pieces of encryption information.
クライアントは、ユーザが、彼らのデータがだれにとって暗号化されているかを決心できるように「反-参照をつけ」られるために与えられたアンカーに関連しているDNと証明書チェーンを表示するメソッドを提供するものとします。 これらが直交した暗号化情報であるのでアンカーを含むドキュメントであると署名されて、これは表示するためのそうしたメソッドと異なっているべきです。
Rescorla & Schiffman Experimental [Page 31] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[31ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
7. Implementation Notes
7. 実装注意
7.1. Preenhanced Data
7.1. データをPreenhancedしました。
While S-HTTP has always supported preenhanced documents, in previous versions it was never made clear how to actually implement them. This section describes two methods for doing so: preenhancing the HTTP request/response and preenhancing the underlying data.
S-HTTPはいつも「前-高め」られたドキュメントを支えましたが、旧バージョンではそれを実際にそれらを実装する方法が明確に決してしませんでした。 このセクションはそうするための2つのメソッドを説明します: HTTP要求/応答を「前-高め」て、基本的なデータを「前-高め」ます。
7.1.1. Motivation
7.1.1. 動機
The two primary motivations for preenhanced documents are security and performance. These advantages primarily accrue to signing but may also under special circumstances apply to confidentiality or repudiable (MAC-based) authentication.
「前-高め」られたドキュメントに関する2つのプライマリ動機が、セキュリティと性能です。 これらの利点は、主として署名に生じますが、特殊事情の下でも秘密性に適用するか、または(MACベース)の認証をrepudiableするかもしれません。
Consider the case of a server which repeatedly serves the same content to multiple clients. One such example would be a server which serves catalogs or price lists. Clearly, customers would like to be able to verify that these are actual prices. However, since the prices are typically the same to all comers, confidentiality is not an issue. (Note: see Section 7.1.5 below for how to deal with this case as well).
繰り返して複数のクライアントに同じ内容をサービスするサーバに関するケースを考えてください。 その一例はカタログかプライスリストに役立つサーバでしょう。 明確に、顧客は、これらが実際の価格であることを確かめたがっています。 しかしながら、すべての挑戦者にとって、価格が通常同じであるので、秘密性は問題ではありません。 (注意: セクション7.1.5未満を見て、)どうまた、本件に対処してくださいか。
Consequently, the server might wish to sign the document once and simply send the cached signed document out when a client makes a new request, avoiding the overhead of a private key operation each time. Note that conceivably, the signed document might have been generated by a third party and placed in the server's cache. The server might not even have the signing key! This illustrates the security benefit of presigning: Untrusted servers can serve authenticated data without risk even if the server is compromised.
その結果、サーバは、一度書類にサインして、クライアントが新しい要求をすると、単にキャッシュされた署名しているドキュメントを出したがっているかもしれません、その都度秘密鍵操作のオーバーヘッドを避けて。 署名しているドキュメントが多分、第三者によって作られて、サーバのキャッシュに置かれたかもしれないことに注意してください。 サーバには、署名キーがしさえしないかもしれません! これは前署名することのセキュリティ利益を例証します: サーバが感染されても、信頼されていないサーバはリスクなしで認証されたデータに役立つことができます。
7.1.2. Presigned Requests/Responses
7.1.2. 要求/応答をPresignedしました。
The obvious implementation is simply to take a single request/response, cache it, and send it out in situations where a new message would otherwise be generated.
明白な実装は、状況でそうでなければ新しいメッセージが生成されるところに単にただ一つの要求/応答を取って、それをキャッシュして、それを出すことです。
7.1.3. Presigned Documents
7.1.3. ドキュメントをPresignedしました。
It is also possible using S-HTTP to sign the underlying data and send it as an S-HTTP messsage. In order to do this, one would take the signed document (a CMS or MOSS message) and attach both S-HTTP headers (e.g. the S-HTTP request/response line, the Content-Privacy- Domain) and the necessary HTTP headers (including a Content-Type that reflects the inner content).
また、S-HTTP messsageとして基本的なデータに署名して、それを送るのにS-HTTPを使用するのも可能です。 これをするために、1つは、署名しているドキュメント(CMSかモスメッセージ)を取って、S-HTTPヘッダ(例えば、S-HTTP要求/応答系列、Content-プライバシードメイン)と必要なHTTPヘッダの両方を付けるでしょう(内側の内容を反映するコンテントタイプを含んでいて)。
Rescorla & Schiffman Experimental [Page 32] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[32ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
SECURE * Secure-HTTP/1.4
Content-Type: text/html
Content-Privacy-Domain: CMS
*が安全なHTTP/1.4コンテントタイプであると機密保護してください: html Contentプライバシーテキスト/ドメイン: cm
Random signed message here...
ここの無作為の署名しているメッセージ…
This message itself cannot be sent, but needs to be recursively encapsulated, as described in the next section.
このメッセージ自体は、次のセクションで説明されるように送ることができませんが、再帰的にカプセル化される必要があります。
7.1.4. Recursive Encapsulation
7.1.4. 再帰的なカプセル化
As required by Section 7.3, the result above needs to be itself encapsulated to protect the HTTP headers. the obvious case [and the one illustrated here] is when confidentiality is required, but the auth enhancement or even the null transform might be applied instead. That is, the message shown above can be used as the inner content of a new S-HTTP message, like so:
必要に応じて、セクション7.3によって、それ自体である必要性を超えた結果はHTTPヘッダを保護するために要約されました。明白なケース[ものはここで例証した]は秘密性が必要ですが、auth増進かヌル変換さえ代わりに適用されるかもしれない時です。 すなわち、上に以下が新しいS-HTTPメッセージの内側の内容として使用されて、好きであることができることが示されたメッセージ
SECURE * Secure-HTTP/1.4
Content-Type: application/s-http
Content-Privacy-Domain: CMS
*が安全なHTTP/1.4コンテントタイプであると機密保護してください: s-http Contentプライバシーアプリケーション/ドメイン: cm
Encrypted version of the message above...
上記のメッセージのバージョンを暗号化します…
To unfold this, the receiver would decode the outer S-HTTP message, reenter the (S-)HTTP parsing loop to process the new message, see that that too was S-HTTP, decode that, and recover the inner content.
受信機は、これを繰り広げるために、外側のS-HTTPメッセージを解読して、新しいメッセージを処理するために(S)HTTP構文解析輪に再入して、それもS-HTTPであったのがわかって、それを解読して、内側の内容を回復するでしょう。
Note that this approach can also be used to provide freshness of server activity (though not of the document itself) while still providing nonrepudiation of the document data if a NONCE is included in the request.
また、NONCEが要求に含まれているならまだドキュメントデータの非拒否を提供している間、サーバ活動(もっとも、いずれのドキュメント自体についてもそうしない)の新しさを提供するのにこのアプローチを使用できることに注意してください。
7.1.5. Preencrypted Messages
7.1.5. メッセージをPreencryptedしました。
Although preenhancement works best with signature, it can also be used with encryption under certain conditions. Consider the situation where the same confidential document is to be sent out repeatedly. The time spent to encrypt can be saved by caching the ciphertext and simply generating a new key exchange block for each recipient. [Note that this is logically equivalent to a multi- recipient message as defined in both MOSS and CMS and so care must be taken to use proper PKCS-1 padding if RSA is being used since otherwise, one may be open to a low encryption exponent attack [HAST96].
前増進は署名でうまくいきますが、また、暗号化と共にそれを一定の条件の下で使用できます。 同じ機密書類が繰り返して出されることになっている状況を考えてください。 缶を暗号化するために暗号文をキャッシュすることによって保存されて、各受取人のために単に新しい主要な交換ブロックを生成しながら費やされた時間。 [モスとCMSの両方で定義されて、RSAが使用されているならさもなければ、低い暗号化解説者攻撃[HAST96]において、開くかもしれないのでそっと歩く適切なPKCS-1を使用するために注意しなければならないためにこれがマルチ受取人メッセージに論理的に同等であることに注意してください。
Rescorla & Schiffman Experimental [Page 33] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[33ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
7.2. Proxy Interaction
7.2. プロキシ相互作用
The use of S-HTTP presents implementation issues to the use of HTTP proxies. While simply having the proxy blindly forward responses is straightforward, it would be preferable if S-HTTP aware proxies were still able to cache responses in at least some circumstances. In addition, S-HTTP services should be usable to protect client-proxy authentication. This section describes how to achieve those goals using the mechanisms described above.
S-HTTPの使用はHTTPプロキシの使用に導入問題を提示します。 プロキシに応答を単に盲目的に進めさせるのが、簡単である間、S-HTTPの意識しているプロキシがまだ少なくともいくつかの事情における応答をキャッシュできるなら、望ましいでしょうに。 さらに、S-HTTPサービスはクライアントプロキシ認証を保護するのにおいて使用可能であるべきです。 このセクションは上で説明されたメカニズムを使用することでそれらの目標を達成する方法を説明します。
7.2.1. Client-Proxy Authentication
7.2.1. クライアントプロキシ認証
When an S-HTTP aware proxy receives a request (HTTP or S-HTTP) that (by whatever access control rules it uses) it requires to be S-HTTP authenticated (and if it isn't already so), it should return the 422 response code (5.7.4).
S-HTTPの意識しているプロキシが(それが使用するどんなアクセス制御規則によるも)それが認証されたS-HTTPであることを必要とする要求(HTTPかS-HTTP)を受け取るとき(それが既にそうでないなら)、422応答コードを返すべきである、(5.7、.4、)
When the client receives the 422 response code, it should read the cryptographic options that the proxy sent and determine whether or not it is willing to apply that enhancement to the message. If the client is willing to meet these requirements, it should recursively encapsulate the request it previously sent using the appropriate options. (Note that since the enhancement is recursively applied, even clients which are unwilling to send requests to servers in the clear may be willing to send the already encrypted message to the proxy without further encryption.) (See Section 7.1 for another example of a recursively encapsulated message)
クライアントが422応答コードを受け取るとき、それは、プロキシが送った暗号のオプションを読んで、その増進をメッセージに適用しても構わないと思っているかどうか決定するべきです。 クライアントが、これらの必要条件を満たしても構わないと思っているなら、それは、適切なオプションを使用することで以前に送った要求を再帰的にカプセル化するべきです。 (増進が再帰的に適用されて、明確のサーバに要求を送りたがっていないクライアントさえ、さらなる暗号化なしで既に暗号化されたメッセージをプロキシに送っても構わないと思っているかもしれないことに注意してください。) (再帰的にカプセル化されたメッセージの別の例に関してセクション7.1を見ます)
When the proxy receives such a message, it should strip the outer encapsulation to recover the message which should be sent to the server.
プロキシがそのようなメッセージを受け取るとき、それは、サーバに送られるべきであるメッセージを回復するために外側のカプセル化を剥取るべきです。
8. Implementation Recommendations and Requirements
8. 実装推薦と要件
All S-HTTP agents must support the MD5 message digest and MAC authentication. As of S-HTTP/1.4, all agents must also support the RSA-MD5-HMAC construction.
すべてのS-HTTPエージェントが、MD5メッセージダイジェストとMACが認証であるとサポートしなければなりません。 また、S-HTTP/1.4現在、すべてのエージェントが、RSA-MD5-HMACが工事であるとサポートしなければなりません。
All S-HTTP agents must support Outband, Inband, and DH key exchange.
すべてのS-HTTPエージェントが、Outband、Inband、およびDHが主要な交換であるとサポートしなければなりません。
All agents must support encryption using DES-CBC.
すべてのエージェントが、暗号化使用がDES-CBCであるとサポートしなければなりません。
Agents must support signature generation and verification using NIST-DSS.
エージェントは、NIST-DSSを使用することで署名世代と検証をサポートしなければなりません。
Rescorla & Schiffman Experimental [Page 34] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[34ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
9. Protocol Syntax Summary
9. プロトコル構文概要
We present below a summary of the main syntactic features of S- HTTP/1.4, excluding message encapsulation proper.
私たちは以下にメッセージカプセル化を除いたS自体HTTP/1.4の主な構文の特徴の概要を提示します。
9.1. S-HTTP (Unencapsulated) Headers
9.1. S-HTTP(Unencapsulated)ヘッダー
Content-Privacy-Domain: ('CMS' | 'MOSS')
Prearranged-Key-Info: <Hdr-Cipher>,<Key>,<Key-ID>
Content-Type: 'message/http'
MAC-Info: [hex(timeofday)',']<hash-alg>','hex(<hash-data>)','
<key-spec>
満足しているプライバシードメイン: ('cm|'こけのもの)、' 根回しされた主要なインフォメーション: <Hdr-暗号>、<の主要な>、<の主要なIDの>コンテントタイプ: 'メッセージ/http'MAC-インフォメーション: '、[(timeofday)に魔法をかけてください、'、'、]、alg>、''十六進法(<ハッシュデータ>)'を論じ尽くしている<'<主要な仕様の>。
9.2. HTTP (Encapsulated) Non-negotiation Options
9.2. HTTP(要約する)譲渡禁止オプション
Key-Assign: <Method>','<Key-Name>','<Lifetime>','
<Ciphers>';'<Method-args>
Encryption-Identity: <name-class>','<key-sel>','<name-args>
Certificate-Info: <Cert-Fmt>','<Cert-Group>
Nonce: <string>
Nonce-Echo: <string>
キーアサイン: '<メソッド>'、'<の主要な名前の>'、'<生涯>'、'<は>';'<メソッド-args>暗号化アイデンティティを解きます'。 'クラス>、''<の主要なselの>''<名argsを命名している<>証明書インフォメーション:' <'本命-Fmt、>、''<は>一回だけを本命と同じくらい分類します'。 <は>の一回だけのエコーを結びます: <ストリング>。
9.3. Encapsulated Negotiation Options
9.3. 交渉オプションであるとカプセル化されます。
SHTTP-Cryptopts: <scope>';'<string>(,<string>)*
SHTTP-Privacy-Domains: ('CMS' | 'MOSS')
SHTTP-Certificate-Types: ('X.509')
SHTTP-Key-Exchange-Algorithms: ('DH', 'RSA' | 'Inband' | 'Outband')
SHTTP-Signature-Algorithms: ('RSA' | 'NIST-DSS')
SHTTP-Message-Digest-Algorithms: ('RSA-MD2' | 'RSA-MD5' | 'NIST-SHS'
'RSA-MD2-HMAC', 'RSA-MD5-HMAC', 'NIST-SHS-HMAC')
SHTTP-Symmetric-Content-Algorithms: ('DES-CBC' | 'DES-EDE-CBC' |
'DES-EDE3-CBC' | 'DESX-CBC' | 'CDMF-CBC' | 'IDEA-CBC' |
'RC2-CBC' )
SHTTP-Symmetric-Header-Algorithms: ('DES-ECB' | 'DES-EDE-ECB' |
'DES-EDE3-EBC' | 'DESX-ECB' | 'CDMF-ECB' | 'IDEA-ECB' |
'RC2-ECB')
SHTTP-Privacy-Enhancements: ('sign' | 'encrypt' | 'auth')
Your-Key-Pattern: <key-use>','<pattern-info>
SHTTP-Cryptopts: '<範囲>';'<ストリング>(<ストリング>)*SHTTPプライバシードメイン:' ('cm|'こけのもの)、' SHTTPはタイプを証明します: ('X.509') SHTTPの主要な交換アルゴリズム: ('DH'、'RSA'|'Inband'|'Outband') SHTTP署名アルゴリズム: ('RSA'| 'NIST-DSS') SHTTPメッセージダイジェストアルゴリズム: ('RSA-MD2'|'RSA-MD5'|'NIST-SHS''RSA-MD2-HMAC'、'RSA-MD5-HMAC''NIST-SHS-HMAC') SHTTPの左右対称の満足しているアルゴリズム: ('デス-CBC'| 'デスエーデCBC'| 'デス-EDE3-CBC'| 'DESX-CBC'| 'CDMF-CBC'| '考え-CBC'| 'RC2-CBC') SHTTPの左右対称のヘッダーアルゴリズム: ('デス-ECB'| 'デスエーデECB'| 'デス-EDE3-EBC'| 'DESX-ECB'| 'CDMF-ECB'| '考えECB'| 'RC2-ECB') SHTTPプライバシー増進: ('署名してください'| ''|'authを暗号化してください') -キーで型に基づいて作ってください、: '<の主要な使用している>'、'<パターンインフォメーション>'
9.4. HTTP Methods
9.4. HTTPメソッド
Secure * Secure-HTTP/1.4
安全な*安全なHTTP/1.4
Rescorla & Schiffman Experimental [Page 35] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[35ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
9.5. Server Status Reports
9.5. サーバ現状報告
Secure-HTTP/1.4 200 OK SecurityRetry 420 BogusHeader 421 <reason>
安全なHTTP/1.4 200OK SecurityRetry420BogusHeader421<理由>。
10. An Extended Example
10. 拡張例
We provide here a contrived example of a series of S-HTTP requests and replies. Rows of equal signs are used to set off the narrative from sample message traces. Note that the actual encrypted or signed message bodies would normally be binary garbage. In an attempt to preserve readability while still using (mostly) genuine messages, the bodies of the requests have been base64 encoded. To regenerate actual S-HTTP messages, it is necessary to remove the base64 encoding from the message body.
私たちは一連のS-HTTP要求と回答の人為的な例をここに提供します。 等号の通りは、サンプルメッセージ跡から物語を引きたたせるのに使用されます。 通常、実際の暗号化されたか署名しているメッセージ本体が2進のゴミであることに注意してください。 まだ(ほとんど)本物のメッセージを使用している間に読み易さを保持する試みでは、要求のボディーはコード化されたbase64です。 実際のS-HTTPメッセージを作り直すために、メッセージ本体からのbase64コード化を取り除くのが必要です。
10.1. A request using RSA key exchange with Inband key reply
10.1. Inbandの主要な回答によるRSAの主要な交換を使用する要求
Alice, using an S-HTTP-capable client, begins by making an HTTP request which yields the following response page:
できるS HTTPクライアントを使用して、アリスは以下の応答ページをもたらすHTTP要求をすることによって、始めます:
============================================================
200 OK HTTP/1.0
Server-Name: Navaho-0.1.3.3alpha
Certificate-Info: CMS,MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqh
kiG9w0BBwEAAKCAM
IIBrTCCAUkCAgC2MA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAlVTMSAwH
gYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc
29uYSBDZXJ0aWZpY2F0ZTAeFw05NDA0MDkwMDUwMzdaFw05NDA4MDIxODM4N
TdaMGcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0e
SwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEYMBYGA1UEA
xMPU2V0ZWMgQXN0cm9ub215MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMy8Q
cW7RMrB4sTdQ8Nmb2DFmJmkWn+el+NdeamIDElX/qw9mIQu4xNj1FfepfJNx
zPvA0OtMKhy6+bkrlyMEU8CAwEAATANBgkqhkiG9w0BAQIFAANPAAYn7jDgi
rhiIL4wnP8nGzUisGSpsFsF4/7z2P2wqne6Qk8Cg/Dstu3RyaN78vAMGP8d8
2H5+Ndfhi2mRp4YHiGHz0HlK6VbPfnyvS2wdjCCAccwggFRAgUCQAAAFDANB
gkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhd
GEgU2VjdXJpdHksIEluYy4xLjAsBgNVBAsTJUxvdyBBc3N1cmFuY2UgQ2Vyd
GlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTQwMTA3MDAwMDAwWhcNOTYwMTA3M
jM1OTU5WjBNMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2Vjd
XJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydGlmaWNhdGUwaTANB
gkqhkiG9w0BAQEFAANYADBVAk4GqghQDa9Xi/2zAdYEqJVIcYhlLN1FpI9tX
Q1m6zZ39PYXK8Uhoj0Es7kWRv8hC04vqkOKwndWbzVtvoHQOmP8nOkkuBi+A
QvgFoRcgOUCAwEAATANBgkqhkiG9w0BAQIFAANhAD/5Uo7xDdp49oZm9GoNc
PhZcW1e+nojLvHXWAU/CBkwfcR+FSf4hQ5eFu1AjYv6Wqf430Xe9Et5+jgnM
Tiq4LnwgTdA8xQX4elJz9QzQobkE3XVOjVAtCFcmiin80RB8AAAMYAAAAAAA
AAAAA==
============================================================ 200 HTTP/1.0サーバー名を承認してください: ナバホ族0.1.3.3、アルファ、証明書インフォメーション: cm MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqh kiG9w0BBwEAAKCAM IIBrTCCAUkCAgC2MA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAlVTMSAwH gYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTAeFw05NDA0MDkwMDUwMzdaFw05NDA4MDIxODM4N TdaMGcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0e SwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEYMBYGA1UEA xMPU2V0ZWMgQXN0cm9ub215MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMy8Q cW7RMrB4sTdQ8Nmb2DFmJmkWn+高架鉄道+NdeamIDElX/qw9mIQu4xNj1FfepfJNx; + lLN1FpI9tX Q1m6zZ39PYXK8Uhoj0Es7kWRv8hC04vqkOKwndWbzVtvoHQOmP8nOkkuBiはQvgFoRcgOUCAwEAATANBgkqhkiG9w0BAQIFAANhAD/5Uo7xDdp49oZm9GoNc PhZcW1e+nojLvHXWAU/CBkwfcR+FSf4hQ5eFu1AjYv6Wqf430Xe9Et5+jgnM Tiq4LnwgTdA8xQX4elJz9QzQobkE3XVOjVAtCFcmiin80RB8AAAMYAAAAAAA AAAAA=です。
Rescorla & Schiffman Experimental [Page 36] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[36ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
Encryption-Identity: DN-1779, null, CN=Setec Astronomy, OU=Persona
Certificate,O="RSA Data Security, Inc.", C=US;
SHTTP-Privacy-Enhancements: recv-required=encrypt
暗号化アイデンティティ: DN-1779、人格ヌル、CN=Setec Astronomy、OU=Certificate、Oは「RSA Data Security Inc.」と等しく、Cは米国と等しいです。 SHTTPプライバシー増進: recvに必要な=は暗号化します。
<A name=tag1 HREF="shttp://www.setec.com/secret"> Don't read this. </A> ============================================================
<A名前=tag1 HREFが等しい、「shttp://www.setec.com/「>ドンはこれを読みませんでした」秘密の。 </は>です。============================================================
An appropriate HTTP request to dereference this URL would be:
適切なHTTPは、このURLが以下の通りであるよう反参照に要求します。
============================================================ GET /secret HTTP/1.0 Security-Scheme: S-HTTP/1.4 User-Agent: Web-O-Vision 1.2beta Accept: *.* Key-Assign: Inband,1,reply,des-ecb;7878787878787878
============================================================ /秘密のHTTP/1.0セキュリティ体系を得てください: S-HTTP/1.4ユーザエージェント: ウェブOビジョン1.2betaは受け入れます: *. *キーアサイン: Inband、1、回答、des-ecb; 7878787878787878
============================================================
============================================================
The added Key-Assign line that would not have been in an ordinary HTTP request permits Bob (the server) to encrypt his reply to Alice, even though Alice does not have a public key, since they would share a key after the request is received by Bob. This request has the following S-HTTP encapsulation:
付加は普通のHTTPでは、要求が、ボブ(サーバ)が彼の回答をアリスに暗号化することを許可します、アリスには、公開鍵がありませんが、要求がボブによって受け取られた後に彼らはキーを共有するでしょう、したがってことでない系列をKey割り当てます。 この要求には、以下のS-HTTPカプセル化があります:
============================================================ Secure * Secure-HTTP/1.4 Content-Type: message/http Content-Privacy-Domain: CMS
============================================================ *が安全なHTTP/1.4コンテントタイプであると機密保護してください: http Contentプライバシーメッセージ/ドメイン: cm
MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBqQIBADBTME0xCzAJBgNVBAYTAlVTMSAw HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29u YSBDZXJ0aWZpY2F0ZQICALYwDQYJKoZIhvcNAQEBBQAEQCU/R+YCJSUsV6XLilHG cNVzwqKcWzmT/rZ+duOv8Ggb7oO/d8H3xUVGQ2LsX4kYGq2szwj8Q6eWhsmhf4oz lvMAADCABgkqhkiG9w0BBwEwEQYFKw4DAgcECFif7BadXlw3oIAEgZBNcMexKe16 +mNxx8YQPukBCL0bWqS86lvws/AgRkKPELmysBi5lco8MBCsWK/fCyrnxIRHs1oK BXBVlsAhKkkusk1kCf/GbXSAphdSgG+d6LxrNZwHbBFOX6A2hYS63Iczd5bOVDDW Op2gcgUtMJq6k2LFrs4L7HHqRPPlqNJ6j5mFP4xkzOCNIQynpD1rV6EECMIk/T7k 1JLSAAAAAAAAAAAAAA== ============================================================
MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBqQIBADBTME0xCzAJBgNVBAYTAlVTMSAw HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29u YSBDZXJ0aWZpY2F0ZQICALYwDQYJKoZIhvcNAQEBBQAEQCU/R+YCJSUsV6XLilHG cNVzwqKcWzmT/rZ+duOv8Ggb7oO/d8H3xUVGQ2LsX4kYGq2szwj8Q6eWhsmhf4oz; ============================================================
The data between the delimiters is a CMS message, RSA enveloped for Setec Astronomy.
デリミタの間のデータはCMSメッセージ、Setec AstronomyのためにおおわれたRSAです。
Bob decrypts the request, finds the document in question, and is ready to serve it back to Alice.
ボブは、要求を解読して、ドキュメントがはっきりしていないのがわかって、アリスにそれをサービスして戻す準備ができています。
Rescorla & Schiffman Experimental [Page 37] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[37ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
An appropriate HTTP server response would be:
適切なHTTPサーバ応答は以下の通りでしょう。
============================================================ HTTP/1.0 200 OK Security-Scheme: S-HTTP/1.4 Content-Type: text/html
============================================================ HTTP/1.0 200OKセキュリティ体系: S-HTTP/1.4コンテントタイプ: テキスト/html
Congratulations, you've won.
<A href="/prize.html"
CRYPTOPTS="Key-Assign: Inband,alice1,reply,des-ecb;020406080a0c0e0f;
SHTTP-Privacy-Enhancements: recv-required=auth">Click here to
claim your prize</A>
============================================================
おめでとうございます、あなたは勝ちました。 「<A hrefは」 /prize.htmlと等しく」CRYPTOPTS=は「以下をキーで割り当てます」。 Inband、alice1、回答、des-ecb(020406080a0c0e0f) SHTTPプライバシー増進: 「>はあなたの賞の</が>であると主張するためにここでクリックする」recvが必要な=auth============================================================
This HTTP response, encapsulated as an S-HTTP message becomes:
S-HTTPメッセージがなるのでカプセル化されたこのHTTP応答:
============================================================ Secure * Secure-HTTP/1.4 Content-Type: message/http Prearranged-Key-Info: des-ecb,697fa820df8a6e53,inband:1 Content-Privacy-Domain: CMS
============================================================ *が安全なHTTP/1.4コンテントタイプであると機密保護してください: http Prearrangedの主要なメッセージ/インフォメーション: des-ecb、697fa820df8a6e53、「不-バンド」: 1つのContentプライバシードメイン: cm
MIAGCSqGSIb3DQEHBqCAMIACAQAwgAYJKoZIhvcNAQcBMBEGBSsOAwIHBAifqtdy x6uIMYCCARgvFzJtOZBn773DtmXlx037ck3giqnV0WC0QAx5f+fesAiGaxMqWcir r9XvT0nT0LgSQ/8tiLCDBEKdyCNgdcJAduy3D0r2sb5sNTT0TyL9uydG3w55vTnW aPbCPCWLudArI1UHDZbnoJICrVehxG/sYX069M8v6VO8PsJS7//hh1yM+0nekzQ5 l1p0j7uWKu4W0csrlGqhLvEJanj6dQAGSTNCOoH3jzEXGQXntgesk8poFPfHdtj0 5RH4MuJRajDmoEjlrNcnGl/BdHAd2JaCo6uZWGcnGAgVJ/TVfSVSwN5nlCK87tXl nL7DJwaPRYwxb3mnPKNq7ATiJPf5u162MbwxrddmiE7e3sST7naSN+GS0ateY5X7 AAAAAAAAAAA= ============================================================
MIAGCSqGSIb3DQEHBqCAMIACAQAwgAYJKoZIhvcNAQcBMBEGBSsOAwIHBAifqtdy x6uIMYCCARgvFzJtOZBn773DtmXlx037ck3giqnV0WC0QAx5f+fesAiGaxMqWcir r9XvT0nT0LgSQ/8tiLCDBEKdyCNgdcJAduy3D0r2sb5sNTT0TyL9uydG3w55vTnW aPbCPCWLudArI1UHDZbnoJICrVehxG/sYX069M8v6VO8PsJS7//hh1yM+0nekzQ5l1p0j7uWKu4W0csrlGqhLvEJanj6dQAGSTNCOoH3jzEXGQXntgesk8poFPfHdtj0 5RH4MuJRajDmoEjlrNcnGl/BdHAd2JaCo6uZWGcnGAgVJ/TVfSVSwN5nlCK87tXl nL7DJwaPRYwxb3mnPKNq7ATiJPf5u162MbwxrddmiE7e3sST7naSN+GS0ateY5X7 AAAAAAAAAAA=============================================================
The data between the delimiters is a CMS message encrypted under a randomly-chosen DEK which can be recovered by computing:
デリミタの間のデータはコンピューティングで回収できる手当たりしだいに選ばれたDEKの下で暗号化されたCMSメッセージです:
DES-DECRYPT(inband:1,697fa820df8a6e53)
デスと同じくらい解読します。(「不-バンド」: 1,697fa820df8a6e53)
where 'inband:1' is the key exchanged in the Key-Assign line in the original request.
'「不-バンド」: 1'がKey-案配で交換されたキーであるところでは、オリジナルの要求に立ち並んでください。
Rescorla & Schiffman Experimental [Page 38] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[38ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
10.2. A request using the auth enhancement
10.2. auth増進を使用する要求
There is a link on the HTML page that was just returned, which Alice dereferences, creating the HTTP message:
リンクがただ返されたHTML形式のページにあって、どのアリスが反参照であるか、そして、作成はHTTPメッセージです:
============================================================ GET /prize.html HTTP/1.0 Security-Scheme: S-HTTP/1.4 User-Agent: Web-O-Vision 1.1beta Accept: *.*
============================================================ /prize.html HTTP/1.0セキュリティ体系を得てください: S-HTTP/1.4ユーザエージェント: ウェブOビジョン1.1betaは受け入れます: *.*
============================================================
============================================================
Which, when encapsulated as an S-HTTP message, becomes:
S-HTTPメッセージとしてカプセル化されると、どれがなるか:
============================================================ Secure * Secure-HTTP/1.4 Content-Type: message/http MAC-Info:31ff8122,rsa-md5,b3ca4575b841b5fc7553e69b0896c416,inband:alice1 Content-Privacy-Domain: CMS
============================================================ *が安全なHTTP/1.4コンテントタイプであると機密保護してください: http MACメッセージ/インフォメーション: 31ff8122、rsa-md5、b3ca4575b841b5fc7553e69b0896c416、「不-バンド」: alice1 Contentプライバシードメイン: cm
MIAGCSqGSIb3DQEHAaCABGNHRVQgL3ByaXplLmh0bWwgSFRUUC8xLjAKU2VjdXJp dHktU2NoZW1lOiBTLUhUVFAvMS4xClVzZXItQWdlbnQ6IFdlYi1PLVZpc2lvbiAx LjFiZXRhCkFjY2VwdDogKi4qCgoAAAAA ============================================================
MIAGCSqGSIb3DQEHAaCABGNHRVQgL3ByaXplLmh0bWwgSFRUUC8xLjAKU2VjdXJp dHktU2NoZW1lOiBTLUhUVFAvMS4xClVzZXItQWdlbnQ6IFdlYi1PLVZpc2lvbiAx LjFiZXRhCkFjY2VwdDogKi4qCgoAAAAA============================================================
The data between the delimiters is a CMS 'Data' representation of the request.
デリミタの間のデータは要求のCMS'データ'表現です。
Rescorla & Schiffman Experimental [Page 39] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[39ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
Appendix: A Review of CMS
付録: cmのレビュー
CMS ("Cryptographic Message Syntax Standard") is a cryptographic
message encapsulation format, similar to PEM, based on RSA's PKCS-7
cryptographic messaging syntax.
CMS(「暗号のメッセージ構文規格」)は暗号のメッセージカプセル化形式です、PEMと同様です、RSAのPKCS-7の暗号のメッセージング構文に基づいて。
CMS is only one of two encapsulation formats supported by S-HTTP, but it is to be preferred since it permits the least restricted set of negotiable options, and permits binary encoding. In the interest of making this specification more self-contained, we summarize CMS here.
CMSはS-HTTPによってサポートされた2つのカプセル化形式の唯一の1つですが、それは、最も制限されなかったセットの交渉可能なオプションを可能にして、2進のコード化を可能にして、好まれることになっています。 この仕様をより自己充足的にすることのために、私たちはCMSをここへまとめます。
CMS is defined in terms of OSI's Abstract Syntax Notation (ASN.1, defined in X.208), and is concretely represented using ASN.1's Basic Encoding Rules (BER, defined in X.209). A CMS message is a sequence of typed content parts. There are six content types, recursively composable:
CMSは、OSIの抽象的なSyntax Notation(X.208で定義されたASN.1)に関して定義されて、ASN.1のBasic Encoding Rules(X.209で定義されたBER)を使用することで具体的に表されます。 CMSメッセージはタイプされた満足している部分の系列です。 6つのcontent typeであり、再帰的に構成可能します:
Data -- Some bytes, with no enhancement.
データ--増進のない数バイト。
SignedData -- A content part, with zero or more signature
blocks, and associated keying materials. Keying materials
can be transported via the degenerate case of no signature
blocks and no data.
SignedData--ゼロに従った満足している部分か、より多くの署名欄、関連および合わせることの材料。 署名欄がなくてまたデータがない堕落したケースで材料を合わせるのを輸送できます。
EnvelopedData -- One or more (per recipient) key exchange
blocks and an encrypted content part.
EnvelopedData--1つ以上(1受取人あたりの)の主要な交換ブロック以上と暗号化された内容は離れています。
DigestedData -- A content part with a single digest block.
DigestedData--1つのダイジェストブロックがある満足している部分。
EncryptedData -- An encrypted content part, with key
materials externally provided.
EncryptedData--外部的に主要資材を供給している暗号化された満足している部分。
Here we will dispense with convention for the sake of ASN.1-impaired readers, and present a syntax for CMS in informal BNF (with much gloss). In the actual encoding, most productions have explicit tag and length fields.
ここに、私たちは、ASN.1によって損なわれた読者のためにコンベンションを省いて、非公式のBNF(多くの艶がある)のCMSのために構文を提示するつもりです。 実際のコード化では、ほとんどの創作が明白なタグと長さの分野を持っています。
Message = *Content
Content = Data | SignedData | EnvelopedData |
DigestedData | EncryptedData
Data = Bytes
SignedData = *DigestAlg Content *Certificates
*CRLs SignerInfo*
EnvelopedData = *RecipientInfo BulkCryptAlg
Encrypted(Content)
メッセージ=*内容内容はデータと等しいです。| SignedData| EnvelopedData| DigestedData| SignedData=*DigestAlg内容*証明書*CRLs SignerInfo*EnvelopedData=*RecipientInfo BulkCryptAlgが暗号化したEncryptedDataデータ=バイト(内容)
Rescorla & Schiffman Experimental [Page 40] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[40ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
DigestedData = DigestAlg Content DigestBytes EncryptedData = BulkCryptAlg Encrypted(Bytes) SignerInfo = CertID ... Encrypted(DigestBytes) ... RecipientInfo = CertID KeyCryptAlg Encrypted(DEK)
DigestAlg DigestedData=内容DigestBytes EncryptedData=BulkCryptAlgはSignerInfo=CertIDを暗号化しました(バイト)… (DigestBytes)を暗号化します… CertID KeyCryptAlgが暗号化したRecipientInfo=(DEK)
Appendix: Internet Media Type message/s-http
付録: インターネットメディアTypeメッセージ/s-http
In addition to defining the S-HTTP/1.4 protocol, this document serves as the specification for the Internet media type "message/s-http". The following is to be registered with IANA.
S-HTTP/1.4プロトコルを定義することに加えて、このドキュメントはインターネットメディアのためのタイプ「メッセージ/s-http」という仕様として機能します。 以下はIANAに登録されることになっています。
Media Type name: message
Media subtype name: s-http
Required parameters: none
Optional parameters: version, msgtype
メディアTypeは以下を命名します。 メッセージメディア「副-タイプ」名: s-http Requiredパラメタ: なにも、Optionalパラメタ: バージョン、msgtype
version: The S-HTTP version number of the enclosed message
(e.g. "1.4"). If not present, the version can be
determined from the first line of the body.
バージョン: 同封のメッセージのS-HTTPバージョン番号、(例えば、「1.4インチ)」 プレゼントでないなら、バージョンはボディーの最初の系列から決定できます。
msgtype: The message type -- "request" or "response".
If not present, the type can be determined from the
first line of the body.
msgtype: 「要求」かタイプ--「応答」というメッセージ。 プレゼントでないなら、タイプはボディーの最初の系列から決定できます。
Encoding considerations: only "7bit", "8bit", or "binary"
are permitted.
問題をコード化します: 「7ビット」、「8ビット」、または「バイナリー」だけ、が受入れられます。
Security considerations: this is a security protocol.
セキュリティ問題: これはセキュリティプロトコルです。
Bibliography and References
図書目録と参照
[BELL96] Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash
Functions for Message Authentication", Preprint.
[BELL96] H. Bellare、M.、カネッティ、R.、Krawczyk、「通報認証のためにハッシュ関数を合わせる」前印刷。
[FIPS-46-1] Federal Information Processing Standards Publication
(FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed
1988 January 22 (supersedes FIPS PUB 46, 1977 January
15).
[FIPS-46-1]連邦政府の情報処理規格公表(FIPSパブ)46-1(データ暗号化規格)は1月22日(1月15日にFIPSパブ46、1977に取って代わる)に1988を再び断言しました。
[FIPS-81] Federal Information Processing Standards Publication
(FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
1980年のDES運転モード、12月2[FIPS-81]連邦政府の情報処理規格公表(FIPSパブ)81、日。
[FIPS-180] Federal Information Processing Standards Publication
(FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17.
[FIPS-180] 1995年の「安全なハッシュ規格」、4月17連邦政府の情報処理規格公表(FIPSパブ)180-1、日。
[FIPS-186] Federal Information Processing Standards Publication
(FIPS PUB) 186, Digital Signature Standard, 1994 May 19.
デジタル署名基準、1994年の19年5月[FIPS-186]連邦政府の情報処理規格公表(FIPSパブ)186日。
Rescorla & Schiffman Experimental [Page 41] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[41ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
[HAST86] Hastad, J., "On Using RSA With Low Exponents in a Public
Key Network," Advances in Cryptology-CRYPTO 95
Proceedings, Springer-Verlag, 1986.
[HAST86]Hastad(「公開鍵ネットワークに低い解説者があるRSAを使用する」ときのJ.)は暗号理論暗号95の議事、追出石-Verlag、1986を進みます。
[JOHN93] Johnson, D.B., Matyas, S.M., Le, A.V., Wilkins, J.D.,
"Design of the Commercial Data Masking Facility Data
Privacy Algorithm," Proceedings 1st ACM Conference on
Computer & Communications Security, November 1993,
Fairfax, VA., pp. 93-96.
[JOHN93]ジョンソン、D.B.、マーチャーシュ、S.M.、Le、A.V.、ウィルキンズ、J.D.、「商業的データマスキング施設データプライバシーアルゴリズムのデザイン」、コンピュータとCommunications Securityの上のProceedings最初のACMコンファレンス、1993年11月、フェアファクス、ヴァージニア、ページ 93-96.
[KRAW96b] Krawczyk, H. personal communication.
[KRAW96b]Krawczyk、H.の個人的なコミュニケーション。
[LAI92] Lai, X. "On the Design and Security of Block Ciphers,"
ETH Series in Information Processing, v. 1, Konstanz:
Hartung-Gorre Verlag, 1992.
[LAI92]レイ、「ブロック暗号のデザインとセキュリティ」のX.、情報Processing、vのETH Series。 1、コンスタンツ: ハルトゥング-Gorre Verlag、1992。
[PKCS-6] RSA Data Security, Inc. "Extended Certificate Syntax
Standard", PKCS-6, Nov 1, 1993.
[PKCS-6]RSA Data Security Inc.「拡張証明書構文規格」、PKCS-6、1993年11月1日。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[RFC-822] Crocker, D., "Standard For The Format Of ARPA Internet
Text Messages", STD 11, RFC 822, August 1982.
[RFC-822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[RFC-1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC
1319, April 1992.
[RFC-1319] Kaliski、B.、「MD2メッセージダイジェストアルゴリズム」、RFC1319、1992年4月。
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC-1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures", RFC 1421, February 1993.
[RFC-1421]リン、J.、「インターネット電子メールのためのプライバシー増進:」 部分I: 「メッセージ暗号化と認証手順」、RFC1421、2月1993日
[RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC
1422, February 1993.
[RFC-1422]ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422、1993年2月。
[RFC-1779] Kille, S., "A String Representation of Distinguished
Names", RFC 1779, March 1995.
[RFC-1779] Kille、S.、「分類名のストリング表現」、RFC1779、1995年3月。
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, September 1993.
解放された[RFC-2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1993年9月。
[RFC-1738] T. Berners-Lee, "Uniform Resource Locators (URLs)", RFC
1738, December 1994.
[RFC-1738]T.バーナーズ・リー、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
Rescorla & Schiffman Experimental [Page 42] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[42ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
[RFC-1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Muliparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[RFC-1847] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMuliparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[RFC-1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME
Object Security Services", RFC 1848, October 1995.
[RFC-1848]クロッカーとS. N.と解放されて、ガルビン、J.とS.マーフィー、「MIMEオブジェクトセキュリティー・サービス」、RFC1848、1995年10月。
[RFC-1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
RFC 1864, October 1995.
[RFC-1864] マイアーズとJ.とM.ローズ、「内容-MD5ヘッダーフィールド」、RFC1864、1995年10月。
[RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1" RFC 2616, June 1999.
[RFC-2616] フィールディングとR.とGettysとJ.とムガール人とJ.とFrystykとH.とMasinterとL.とリーチとP.とT.バーナーズ・リー、「HTTP/1.1インチRFCハイパーテキスト転送プロトコル--2616、1999年6月。」
[RFC-2617] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A. and L. Stewart, "HTTP Authentication: Basic
and Digest Access Authentication", RFC 2617, June 1999.
[RFC-2617] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC-2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[SHTML] Rescorla, E. and A. Schiffman, "Security Extensions For
HTML", RFC 2659, August 1999.
[SHTML] レスコラとE.とA.シフマン、「HTMLのためのセキュリティ拡大」、RFC2659、1999年8月。
[VANO95] B. Prennel and P. van Oorschot, "On the security of two
MAC algorithms", to appear Eurocrypt'96.
[VANO95]B.PrennelとP.は、Eurocrypt96年で現れるように「2つのMACアルゴリズムのセキュリティ」でOorschotをバンに積みます。
[X509] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
[X509]CCITT推薦X.509(1988)、「ディレクトリ--認証、フレームワーク、」
Security Considerations
セキュリティ問題
This entire document is about security.
この全体のドキュメントはセキュリティに関するものです。
Rescorla & Schiffman Experimental [Page 43] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[43ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
Authors' Addresses
作者のアドレス
Eric Rescorla RTFM, Inc. 30 Newell Road, #16 East Palo Alto, CA 94303
エリックレスコラRTFM Inc.30ヌーエルRoad、東パロアルト、#16カリフォルニア 94303
Phone: (650) 328-8631 EMail: ekr@rtfm.com
以下に電話をしてください。 (650) 328-8631 メールしてください: ekr@rtfm.com
Allan M. Schiffman SPYRUS/Terisa 5303 Betsy Ross Drive Santa Clara, CA 95054
アランM.シフマンSPYRUS/Terisa5303ベッツィ・ロス・Driveサンタクララ、カリフォルニア 95054
Phone: (408) 327-1901 EMail: ams@terisa.com
以下に電話をしてください。 (408) 327-1901 メールしてください: ams@terisa.com
Rescorla & Schiffman Experimental [Page 44] RFC 2660 The Secure HyperText Transfer Protocol August 1999
安全な[44ページ]RFC2660のハイパーテキスト転送プロトコル1999年8月に実験的なレスコラとシフマン
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rescorla & Schiffman Experimental [Page 45]
レスコラとシフマンExperimentalです。[45ページ]
一覧
スポンサーリンク
