[要約] RFC 2660は、セキュアなHTTP通信を提供するためのプロトコルであり、要約するとその目的はセキュアなデータ転送を実現することです。
Network Working Group E. Rescorla
Request for Comments: 2660 RTFM, Inc.
Category: Experimental A. Schiffman
Terisa Systems, Inc.
August 1999
The Secure HyperText Transfer Protocol
安全なハイパーテキスト転送プロトコル
Status of this 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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
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.
このメモは、World Wide Webの基礎を形成するHyperText Transfer Protocol（HTTP）を使用して送信されたメッセージを保護するための構文を説明しています。Secure HTTP（S-HTTP）は、トランザクションの機密性、信頼性/整合性、および原産地の非整合性のために、独立して適用可能なセキュリティサービスを提供します。
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
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
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.
World Wide Web（www）は、インターネットユーザーの間で広く受け入れられている分散ハイパーメディアシステムです。WWWブラウザーは他の既存のインターネットアプリケーションプロトコルをサポートしていますが、WWWクライアントとサーバー間で使用されるネイティブおよびプライマリプロトコルは、ハイパーテキスト転送プロトコル（HTTP）[RFC-2616]です。Webの使いやすさにより、多くのアプリケーションのクライアント/サーバーアーキテクチャとしての広範な雇用が促されました。そのようなアプリケーションの多くは、クライアントとサーバーが互いに認証し、機密情報を秘密に交換できるようにする必要があります。元の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.
Secure HTTP（S-HTTP）は、幅広いアプリケーションの自発的な商業取引を可能にするために、HTTPクライアントサーバーペア間の安全な通信メカニズムを提供します。私たちの設計意図は、各取引の関係者間のオプション交渉を通じて、複数の直交操作モード、主要な管理メカニズム、信頼モデル、暗号化アルゴリズム、およびカプセル化形式をサポートする柔軟なプロトコルを提供することです。
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.
Secure 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.
Secure HTTPは、HTTPクライアントとサーバーにさまざまなセキュリティメカニズムを提供し、世界中のWebに可能な幅広い潜在的な最終用途に適したセキュリティサービスオプションを提供します。プロトコルは、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]および[Moss]に限定されません。S-HTTPは、さまざまな実装間の相互操作をサポートし、HTTPと互換性があります。S-HTTP Awareクライアントは、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は、対称キーのみの操作モードをサポートするため、クライアント側の公開キー証明書（またはパブリックキー）を必要としません。
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を使用すると、Clearのネットワーク上に機密データを送信する必要はありません。
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対DSA、暗号化用のDES対RC2など）;証明書の選択（「ブロックバスタービデオ証明書」で署名してください）。
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は、[RFC-2617]に記載されている消化器の認証とは異なります。これは、公開キーの暗号化とその結果、デジタル署名機能をサポートし、機密性を提供するという点で異なります。
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について説明します。これは、PKCS-7の後継者である暗号化メッセージの構文（CMS）[CMS]をサポートする以前のメモとは異なるという点で、以前のメモとは異なります。したがって、現在、Diffie-Hellmanと（NIST）デジタル署名標準暗号システムをサポートしています。RSAモードで使用されるCMSは、PKCS-7と互換性のあるワイヤー上のビットです。
The creation of an S-HTTP message can be thought of as a a function with three inputs:
S-HTTPメッセージの作成は、3つの入力を持つ関数と考えることができます。
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. クリアテキストメッセージ。これは、HTTPメッセージまたは他のデータオブジェクトのいずれかです。ClearTextメッセージは透過的に運ばれるため、ヘッダーとすべてのHTTPの任意のバージョンをS-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.
クリアテキストメッセージをS-HTTPメッセージに変換するために必要な処理手順は、セクション2および3で説明されています。送信者と受信者の設定をマージするために必要な処理手順は、セクション3.2で説明されています。
The recovery of an S-HTTP message can be thought of as a function of four distinct inputs:
S-HTTPメッセージの回復は、4つの異なる入力の関数と考えることができます。
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を参照してください。）
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.)
また、受信者は、適用された拡張機能が、送信者が適用すると言った拡張機能（上記の入力4を入力）と（上記の入力2を入力）と同様に、S-HTTPを確認するための現在の設定の両方と一致することを確認することもできます。メッセージは適切に変換されました。このプロセスでは、ユーザーがユーザーが許容できることを確認するために、ユーザーとの対話が必要になる場合があります。（このトピックの詳細については、セクション6.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.
さらに、課題反応（「ノンセ」）メカニズムが提供され、当事者がトランザクションの鮮度を保証できるようにします。
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.
デジタル署名の拡張機能が適用されている場合、適切な証明書がメッセージに添付され（おそらく証明書チェーンとともに）、送信者が受信者が必要な証明書（チェーン）を個別に取得することを期待する場合があります。
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つはパブリックキーエンベロープキーエクスチェンジを使用し、もう1つは外部から配置されたキーを使用します。
In the former case, the symmetric-key cryptosystem parameter is passed encrypted under the receiver's public key.
前者の場合、対称キー暗号システムパラメーターは、受信者の公開鍵の下で暗号化されます。
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つに指定されたキー識別情報を使用して、事前に配置されたセッションキーを使用してコンテンツを暗号化します。
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.
Secure HTTPは、メッセージの整合性と送信者の信頼性を、メッセージ認証コード（MAC）の計算を介してメッセージのメッセージの信頼性を確認する手段を提供します。方法の、例えば、手動の取り決めまたは「Inband」キー管理。この手法では、公開キーの暗号化も暗号化の使用も必要ありません。
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.
このメカニズムは、トランザクション自体に（サードパーティの）非整合性を提供せずに、当事者がトランザクションで互いに確実に識別できるようにすることが適切な場合にも役立ちます。このメカニズムの提供は、トランザクションに「署名」するアクションはユーザーにとって明示的かつ意識的であるべきであるというバイアスによって動機付けられていますが、多くの認証ニーズ（つまり、アクセス制御）は、保持する軽量メカニズムで満たすことができます。キー交換のためのパブリックキー暗号化のスケーラビリティ利点。
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メッセージのヘッダーは、必要に応じて、httpメッセージのヘッダー許容可能です（ただし、当事者間で最大クロックスキューするための手当を実装する必要がありますが、これは指定しないことを選択します）。
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.
アプリケーション要件の幅広い範囲、ユーザーの洗練の変動、および異種の実装制約に直面して、世界的なWebの安全なドキュメントの広範な採用を奨励するために、HTTPはさまざまな実装オプションに意図的に耐えます。実装の推奨事項と要件については、セクション8を参照してください。
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 cryptographically enhanced.
構文的には、安全なHTTPメッセージはHTTPと同じであり、リクエストまたはステータスラインに続いてヘッダーとボディで構成されます。ただし、ヘッダーの範囲は異なり、ボディは通常、暗号化されて強化されています。
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を使用しています。構文の説明については、そのドキュメントを参照する必要があります。
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」を使用する必要があります。その結果、Secure-HTTPおよびHTTP処理は同じTCPポートで混合されています。たとえば、ポート80。
Secure * Secure-HTTP/1.4
SECURE * SECUER-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.
プロキシを介して通信する場合、リクエスト-URIは絶対的なもので構成されている必要があります。通常、Rel Pathセクションは「*」に置き換えて、渡された情報をクリアに最小限に抑える必要があります。（例：http：//www.terisa.com/*）;プロキシは、この情報の適切な量を削除して、トラフィック分析の脅威を最小限に抑える必要があります。より多くの情報を提供することが適切な状況については、セクション7.2.2.1を参照してください。
S-HTTP responses should use the protocol designator "Secure-HTTP/1.4". For example:
S-HTTP応答では、プロトコル指定子「Secure-HTTP/1.4」を使用する必要があります。例えば：
Secure-HTTP/1.4 200 OK
secure-http/1.4 200 ok
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.
安全なHTTP応答ラインのステータスは、包装されていないHTTP要求の成功または失敗について何も示していないことに注意してください。セキュアなHTTP処理が成功した場合、サーバーは常に200 OKを使用する必要があります。これにより、正しい受信者がカプセル化されたデータから決定できる要求の成功または失敗の分析が防止されます。すべてのケースのバリエーションを受け入れる必要があります。
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.
このセクションで説明するヘッダー行は、安全なHTTPメッセージのヘッダーになります。「コンテンツタイプ」と「コンテンツプリバシードメイン」を除くすべてがオプションです。メッセージ本文は、2つの連続したCRLFによってヘッダーブロックから分離されます。
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要求/応答ラインに続くヘッダーブロックを指し、連続したCRLFを「S-HTTPヘッダー」として集合的に前に示します。
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]で定義されている形式を指します。
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
The message/http content type is defined in RFC-2616.
メッセージ/HTTPコンテンツタイプは、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メッセージである場合、コンテンツタイプは「アプリケーション/s-HTTP」でなければなりません。（これの定義については付録を参照してください。）
It is intended that these types be registered with IANA as MIME content types.
これらのタイプは、MIMEコンテンツタイプとして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ヘッダー自体が事前に強化されることを要求することなく、事前に強化されたデータ（特に先見の明のあるデータ）を渡すための有用なメカニズムです。
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'.
MOSSのコンテンツタイプは、適用される暗号化処理を説明する許容可能なMIMEコンテンツタイプでなければなりません。（例：MultiPart/署名）。内部コンテンツのコンテンツタイプは、その内部コンテンツに対応するコンテンツタイプの行で説明されており、HTTPメッセージについては「メッセージ/HTTP」でなければなりません。
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:
この仕様では、名前のキー、インバンド、アウトバンドを交換する2つの方法を定義します。INBANDは、対応するメソッドのキー割り当てヘッダーを使用して、セッションキーが以前に交換されたことを示します。アウトバンドの配置は、おそらくデータベースアクセスを介して、またはキーボード入力からユーザーがすぐに提供する可能性のある特定の名前に対応するキー資料にエージェントが外部アクセスできることを意味します。ヘッダーラインの構文は次のとおりです。
Prearranged-Key-Info =
"Prearranged-Key-Info" ":" Hdr-Cipher "," CoveredDEK "," CoverKey-ID
CoverKey-ID = method ":" key-name
CoveredDEK = *HEX
method = "inband" | "outband"
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.
チェーンをチェーンするには、チェーンを開始するために初期化ベクトル（IV）[FIPS-81]が必要ですが、その情報はこのフィールドによって伝えられません。むしろ、使用されている暗号化形式に内部に渡す必要があります。同様に、使用されるバルク暗号はこの方法で指定されています。
<Hdr-Cipher> should be the name of the block cipher used to encrypt the session key (see section 3.2.4.7)
<hdr-cipher>は、セッションキーを暗号化するために使用されるブロック暗号の名前である必要があります（セクション3.2.4.7を参照）
<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.
<CafterDek>は、カプセル化されたメッセージが暗号化された保護されたデータ暗号化キー（別名トランザクションキー）です。送信エージェントによって適切に（ランダムに）生成され、指定されたヘッダー暗号を使用してネゴシエートキー（別名セッションキー）のカバーの下で暗号化され、その後ヘックスに変換される必要があります。
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.
一部のコンテンツプリバシードメイン、特にモスと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.
そのような状況では、事前に配置されたキー-INFOフィールドを使用する必要はありません。むしろ、ネイティブの構文が推奨されます。ただし、この状況では、キー割り当てと交換されたキーが使用される場合があります。
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):
このヘッダーは、メッセージの信頼性チェックを提供するために使用され、メッセージ認証と整合性の両方を提供し、メッセージテキストから計算された時間、時間（オプション - リプレイ攻撃を防ぐ）、およびクライアントとサーバーの間の共有秘密を提供します。Macは、S-HTTPメッセージのカプセル化されたコンテンツで計算する必要があります。S-HTTP/1.1は、MACが次のアルゴリズムを使用して計算する必要があることを定義しました（ '||'は連結を意味します）：
MAC = hex(H(Message||[<time>]||<shared key>))
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日00:00:00 GMT（UNIXエポック）以降、ネットワークバイトの順序で秒数秒を表す署名されていない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>)
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 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.
元のHMAC構造は、ハッシュ出力の長さに等しい長さのキーを使用するためです。異なる長さのキーを使用することは安全であると考えられていますが（ハッシュ関数自体の長さを超えて強度を上げることはできませんが、より短いキーを使用して減らすことができます。）[kraw96b]ハッシュの長さよりも長い共有キー（パスフレーズなど）の使用。この手法が短いキーの強度を高めることはないことは、（明らかですが）注目に値します。
The format of the MAC-Info line is:
Mac-INFO行の形式は次のとおりです。
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
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-IDは、キー割り当てヘッダーラインを使用してバインドされたキーまたは後で説明したアウトバンドメソッドと同じ方法でバインドされたキーを参照できます。「null」キースペックの使用は、ゼロの長さキーが使用されたことを意味し、したがって、Macは単にメッセージテキストのハッシュを表し、（オプションでは）時間を表します。特別なキースペック「Dek」とは、次のメッセージ本文を暗号化するために使用されるデータ交換キーを指します（次のメッセージ本文が暗号化されていない状況でDEKキースペックを使用するのはエラーです）。
If the time is omitted from the MAC-Info line, it should simply not be included in the hash.
MAC-INFOラインから時間が省略されている場合、ハッシュに単純に含めるべきではありません。
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基本認証モードのより高度な同等物を提供できることに注意してください。ただし、パスワードはプライベートのままであり、メッセージの整合性を保証できます。さらに、これはいかなる種類の暗号化もなく達成できます。
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-INFOは、メッセージの高速メッセージの整合性検証（非整合性の喪失時）を許可します。
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-INFOフィールドを使用する必要はない対称整合性保護をサポートしている可能性が高いことに注意してください。むしろ、ネイティブの構文が推奨されます。ただし、この状況では、キー割り当てと交換されたキーが使用される場合があります。
The content of the message is largely dependent upon the values of the Content-Privacy-Domain and Content-Transfer-Encoding fields.
メッセージの内容は、コンテンツプリバシードメインの値とコンテンツ移動エンコードフィールドに大きく依存しています。
For a CMS message, with '8BIT' Content-Transfer-Encoding, the content should simply be the CMS message itself.
「8ビット」コンテンツ転送エンコードを備えたCMSメッセージの場合、コンテンツは単にCMSメッセージ自体である必要があります。
If the Content-Privacy-Domain is MOSS, the content should consist of a MOSS Security Multipart as described in RFC1847.
Content-Privacy-DomainがMossの場合、コンテンツはRFC1847で説明されているようにMossセキュリティマルチパートで構成する必要があります。
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メッセージである場合があります。この場合、クリアコンテンツが取得されるか、プライバシーの強化が削除されなくなるまでプライバシーの強化を解き放つ必要があります。（これにより、シーケンシャル署名および包括された機能強化などの機能強化の埋め込みが許可されます。）すべての拡張機能を削除できる場合、最終的な非強化コンテンツは、コンテンツタイプの行で特に指定されない限り、有効な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で説明されています。
Content-Privacy-Domain 'CMS' follows the form of the CMS standard (see Appendix).
Content-Privacy-Domain 'CMS'は、CMS標準の形式に従います（付録を参照）。
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つの直交軸で進行する場合があります。メッセージは、署名、暗号化された、または両方であるか、どちらかです。S-HTTPの「AUTH」保護モードは、セクション2.3.6のMAC-INFOヘッダーを介してCMSコーディングとは独立して提供されていることに注意してください。CMSは「DigestedData」タイプをサポートしていますが、「KeyDigestedData」タイプをサポートしていないためです。
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 either case, a purely signed message is precisely CMS compliant.
この拡張機能は、「SignedData」タイプのCMSを使用します。デジタル署名が使用される場合、適切な証明書をCMSで指定したように、適切な証明書をメッセージ（おそらく証明書チェーンとともに）に添付することができます。または、送信者は、受信者が証明書（および/またはチェーン）を個別に取得することを期待する場合があります。これの明示的に許可されたインスタンスは、証明されているパブリックコンポーネントに対応するプライベートコンポーネントで署名された証明書であることに注意してください。これは、自己署名証明書と呼ばれます。もしあれば、そのような証明書に与える重みは、純粋にローカルな問題です。どちらの場合でも、純粋に署名されたメッセージはまさにCMS準拠です。
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の下で（「封筒」タイプのいずれかを使用）包み込むように正確に実行されます。この方法で暗号化されたメッセージは、署名されたものであろうと、CMSに準拠しています。署名と暗号化の両方のメッセージを作成するには、CMS SignedDataの生産を作成し、CMSで説明されているように封筒にカプセル化します。
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.
これは、「暗号化されたData」タイプのCMSを使用します。このモードでは、事前に配置されたセッションキーのカバーの下で暗号化されたDEKを使用してコンテンツを暗号化します（このキーの交換方法は後で説明します）。IVは、暗号化された暗号化された要素の暗号化されたContentinfoタイプにあります。署名と暗号化の両方のメッセージを作成するには、CMS SignedDataの生産を作成し、CMSで説明されているように暗号化されたDataでカプセル化します。
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ヘッダーのコンテンツタイプの行に一致するコンテンツタイプを持つMIME準拠のメッセージである必要があります。暗号化されたメッセージは、MultiPart/暗号化されたものを使用する必要があります。署名されたメッセージは、MultiPart/署名されたものを使用する必要があります。ただし、MultiPart/署名はキーイング素材を伝えないため、最初の部分がアプリケーション/Mosskey-Dataであり、2番目の部分が署名を検証するために使用する証明書を伝達するためにMultiPart/MultiPart/Mixedである場合にMultiPart/Mixedを使用することはできません。
Implementation Note: When both encryption and signature are applied by the same agent, signature should in general be applied before encryption.
実装注：暗号化と署名の両方が同じエージェントによって適用される場合、一般に暗号化前に署名を適用する必要があります。
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ヘッダーにも表示される場合があります。
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]であることに注意してください。
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.
ホストヘッダーは、要求されているリソースのインターネットホストとポート番号を特定します。このヘッダーは、このメッセージを解釈できる複数の潜在的なセキュリティコンテキストの間で明確にするために使用する必要があります。アンラップされていないHTTPメッセージには、独自のホストフィールドがあることに注意してください（HTTP/1.1メッセージであると仮定します）。これらのフィールドが一致しない場合、サーバーは400ステータスコードで応答する必要があります。
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.
接続フィールドは、s-HTTPヘッダーでHTTPヘッダーとまったく同じセマンティクスを持っています。これにより、S-HTTPで永続的な接続を使用できます。
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リクエスト/応答のヘッダー。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.
セクション3.2で説明されているように、潜在的なメッセージ受信者の暗号化設定を伝えているように、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]のトピックであり、ここでは扱われません。
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-metric-content-algorithms：recv-optional = 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ヘッダーで使用される）を定義します。
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"
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>値は、これがプライバシー強化メッセージを受信するのではなく、エージェントのアクションがメッセージを送信する際のアクションが何であるかを指すかどうかを示します。特定のモードアクションペアの場合、リストされている拡張機能（<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-optional：'他の当事者がそれを使用する場合、エージェントは拡張を処理しますが、拡張なしでメッセージを喜んで処理します。
'recv-required:' The agent will not process messages without this enhancement.
'Recv-Required：'エージェントは、この強化なしでメッセージを処理しません。
'recv-refused:' The agent will not process messages with this enhancement.
'recv-refused：'エージェントは、この拡張でメッセージを処理しません。
'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-optional：'この拡張を拒否するエージェントに遭遇したとき、エージェントはそれを提供しません。また、それを必要とするエージェントに遭遇すると、このエージェントはそれを提供します。
'orig-required:' The agent will always generate the enhancement.
'Orig-Required：'エージェントは常に強化を生成します。
'orig-refused:' The agent will never generate the enhancement.
'Orig-Refused：' 'エージェントは強化を生成することはありません。
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-val>が未定義のままになっている場合は、デフォルトに設定されると想定する必要があります。エージェントによって指定されたキーは、そのフィールドのデフォルトの<keyval>の任意のキーの外観を上書きしなければなりません。
For ciphers with variable key lengths, values may be parametrized
using the syntax <cipher>'['<length>']'
For example, 'RSA[1024]' represents a 1024 bit key for RSA. Ranges may be represented as
たとえば、「RSA [1024]」はRSAの1024ビットキーを表します。範囲はとして表される場合があります
<cipher>'['<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)
and
そしてと及びアンド並びに且つ兼又共それですると亦だからそれからはたまた
<cipher>[x], <cipher>[x-1],...<cipher>[y] (if 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.
このような暗号にSimply <cipher>を使用することは、指定された暗号で可能な最大範囲として読み取らなければなりません。
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-Privacy-Domainタイプを指します。許容可能な値はそこに記載されています。例えば、
SHTTP-Privacy-Domains: orig-required=cms;
recv-optional=cms,MOSS
would indicate that the agent always generates CMS compliant messages, but can read CMS or MOSS (or, unenhanced messages).
エージェントは常にCMS準拠のメッセージを生成しますが、CMSまたはMOSS（または強化されていないメッセージ）を読み取ることができることを示します。
This indicates what sort of Public Key certificates the agent will accept. Currently defined values are 'X.509' and 'X.509v3'.
これは、エージェントがどのような公開キー証明書を受け入れるかを示します。現在定義されている値は「x.509」と「x.509v3」です。
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」、「アウトバンド」、「INBAND」です。DHは、diffie-hellman x9.42スタイルの封筒を指します。[DH] RSAはRSAの包囲を指します。アウトバンドとは、何らかの外部キー契約を指します。
Inband refers to section 3.3.3.1.
インバンドとは、セクション3.3.3.1を指します。
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
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.
このヘッダーは、どのデジタル署名アルゴリズムを使用できるかを示します。定義された値は「RSA」[PKCS-1]および「NIST-DSS」[FIPS-186]です。NIST-DSSとRSAは可変長さモジュリを使用しているため、セクション3.2.3のパラメーター化構文を使用する必要があります。キー（およびその長さ）がパブリックキー証明書で指定されているため、キーの長さの仕様は特定の証明書の受容性と相互作用する場合があることに注意してください。
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」[RFC-1321]、 'nist-shs' [fips-180]です。
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-DES IN CIPHERブロックチェーン（CBC）モード[FIPS-81] Des-Ede-CBC-2キー3DE外側のCBCモードの暗号化デクリプトエンドリプトDESX-CBC-RSAのCBCモードIDEA-CBCのIDEA-IDEA CBC MODE CDMF-CBC-IBMのCDMF（弱体化されたキーDES）のRSAのRC2[John93] CBCモード
Since RC2 keys are variable length, the syntax of section 3.2.3 should be used.
RC2キーは長さが変動するため、セクション3.2.3の構文を使用する必要があります。
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-DES in Electronic CodeBook（ECB）モード[FIPS-81] DES-EDE-ECB-2キー3DES ECBモードでエンクリプトデクライプエンクリプトを使用しますDES-EDE3-ECB-3キー3DEECBモードのDecrypt-Encrypt desx-ecb-rsaのdesx in ecbモードIdea-ecb-Idea RC2-ECB-ECBモードCDMF-ECBでのRSAのRC2-IBMのCDMFのECBモードのCDMF
Since RC2 is variable length, the syntax of section 3.2.3 should be used.
RC2は長さが変動するため、セクション3.2.3の構文を使用する必要があります。
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」は、古いMAC構造を使用してS-HTTP/1.1から持続します。トークンのRSA-MD2-HMAC '、「RSA-MD5-HMAC」、および「NIST-SHS-HMAC」は、それぞれMD2、MD5、およびSHA-1アルゴリズムで2.3.6の新しいHMAC構造を示しています。
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.
このヘッダーは、適用するセキュリティ強化を示します。考えられる値は、メッセージが署名、暗号化された、または認証されている（つまり、MACで提供される）かどうかを示す「符号」、「暗号化」、および「認証」です。
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"
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-Key-INFO構文を使用して、トランザクションキーの暗号化に使用されるキー名に目的の値を指定します。パターンINFO構文は、一連のコンマ分離された正規表現で構成されています。カンマは、再スラッシュが正体に表示される場合は、バックスラッシュで逃げる必要があります。最初のパターンが最も好まれていると想定されるべきです。
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-Keyパターンは、Mac Authenticatorに使用するために望ましい名前フォームを指定します。パターンINFO構文は、一連のコンマ分離された正規表現で構成されています。カンマは、再スラッシュが正体に表示される場合は、バックスラッシュで逃げる必要があります。最初のパターンが最も好まれていると想定されるべきです。
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:
このパラメーターは、デジタル署名の拡張に署名するために受け入れられるキーのパターンまたはパターンを説明しています。署名キーのパターンINFO構文は次のとおりです。
pattern-info = name-domain "," pattern-data
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」です。このパラメーターは、区別された名前のフィールドに目的の値を指定します。DNSはRFC1779で指定されているように表されていると見なされますが、フィールド間のフィールドと空白の順序は重要ではありません。
All RFC1779 values should use ',' as a separator rather than ';', since ';' is used as a statement separator in S-HTTP.
すべてのRFC1779値は、「;」ではなく「セパレーター」として「」を使用する必要があります。S-HTTPのステートメントセパレーターとして使用されます。
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.
Pattern-Dataは修正されたRFC1779文字列で、正規表現はフィールド値として許可されています。パターンマッチはフィールドで実行され、不特定のフィールドは任意の値と一致します（したがって、DN-Patternを完全に不特定のままにして、任意のDNを許可します）。証明書チェーンも同様に一致する場合があります（名前の従属なしの証明書を許可するため）。発行者を指定する必要はありませんが、DNチェーンは、特定の証明書の発行者が当面の右側に左から右に注文すると見なされます。後続の「」。DNSのシーケンスが絶対であることを示します。すなわち右側に最も遠いのはルートです。
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>
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ペルソナCA（名前の従属を使用する）によって認定されたキーで署名することを要求するには、以下の式を使用できます。Comma（RFC1779 Field Separator）を保護するために引用符を引用するRFC1779の使用と、DOTを保護するためのPOSIX 1003.2の使用に注意してください（正規表現メタカラクター）。
Your-Key-Pattern: signing-key, DN-1779, /OU=Persona Certificate, O="RSA Data Security, Inc\."/
Your-Key-Pattern：Singing-Key、DN-1779、 /ou = persona証明書、o = "rsa data security、inc \。" /
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
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-Required」など）は、明示的に上書きされない限り暗黙的にマージされます。
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;
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
There are a number of options that are used to communicate or identify the potential recipient's keying material.
潜在的な受信者のキーイング素材を通信または特定するために使用される多くのオプションがあります。
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-Identity =
"Encryption Identity" ":" name-class,key-sel,name-arg
name-class = "DN-1779" | MOSS name forms
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名フォームを追加して、より便利な形式の著名な名前を表します。
The argument is an RFC-1779 encoded DN.
引数は、RFC-1779エンコードDNです。
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:
明示的な証明書フェッチなしで暗号化 - アイデンティティヘッダーによって指定されたDNSの公開キー操作を受信機が許可することを許可するために、送信者は証明書INFOオプションに認定情報を含めることができます。このオプションの形式は次のとおりです。
Certificate-Info: <Cert-Fmt>','<Cert-Group>
<Cert-Fmt> should be the type of <Cert-Group> being presented.
<cert-fmt>は、提示される<cert-group>のタイプである必要があります。
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」です。CMS証明書グループは、SignerINFOフィールドの有無にかかわらず証明書のシーケンスを含むベース64エンコードCMS SignedDataメッセージとして提供されます。PEM形式の証明書グループは、コンマ区切りのBase64エンコードPEM証明書のリストです。
Multiple Certificate-Info lines may be defined.
複数の証明書INFO行を定義できます。
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
Key-name = string
Lifetime = "this" | "reply" | ""
Method ="inband"
Ciphers = "null" | Cipher+
Cipher" = <Header cipher from section 3.2.4.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.
Key-Nameは、このキーをバインドする象徴的な名前です。暗号は、このキーが潜在的に適用可能な暗号のリストです（セクション3.2.4.7のヘッダー暗号のリストを参照）。キーワード「null」は、あらゆる暗号で使用するのに不適切であることを示すために使用する必要があります。これは、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.
Lifetimeは、このメッセージの受信者が送信者がそのキーを受け入れることを期待できる最長期間の表現です。「これ」は、この伝送を読み取るためだけに有効である可能性が高いことを示しています。「返信」は、このメッセージへの返信に役立つことを示します。Reply Lifetimeのキーが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つである必要があります。現在定義されている唯一の値は、インバンドキー（つまり、直接割り当て）を指す「インバンド」です。
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と呼ばれます。
Key-ID = method ":" key-name
key-id = method "：" key-name
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:
これは、発見されたキーをシンボリック名に直接割り当てることを指します。Method-argsは、次のように16進数でエンコードされた目的のセッションキーである必要があります。
Key-Assign: inband,akey,reply,DES-ECB;0123456789abcdef
key-assign：inband、akey、neply、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リクエストにある必要があります。したがって、暗号化されていないメッセージでの使用は許可されていません。
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.
Noncesは不透明で一時的な、セッション指向の識別子であり、新鮮さのデモンストレーションを提供するために使用される可能性があります。ノンセの値は局所的な問題ですが、それらは、オリジネーターによって生成される単純な乱数である可能性があります。値は、単に受信者によって返されるように提供されます。
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-Echoヘッダーラインで返される必要があります。セクション4.1.1を参照してください。
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ヘッダーラインに多くのヘッダーを組み合わせることができます。これらのヘッダーが適用されるアンカーの名前は、「スコープ」パラメーターで示されています。
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とそれが適用される参照のリストを提供します。（HTMLの場合、これらの参照は名前タグを使用して名前が付けられます）。名前は、スコープ属性のコンマ分離リストとして提供され、セミコロンによって次のヘッダーラインから分離されています。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>
For example:
例えば：
SHTTP-Cryptopts: scope=tag1,tag2;
SHTTP-Privacy-Domains:
orig-required=cms; recv-optional=cms,MOSS
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.
メッセージにSHTTP-Cryptoptsラインにグループ化されたS-HTTPネゴシエーションヘッダーとヘッダーの両方が含まれている場合、他のヘッダーは、SHTTP-Cryptoptsラインにバインドされていないすべてのアンカーに適用されるように使用されます。これは、オールオアナッシングの提案であることに注意してください。つまり、SHTTP-CRYPTOPTSヘッダーがオプションを参照にバインドする場合、いくつかのオプションヘッダーがバインドオプションに表示されない場合でも、これらのグローバルオプションは適用されません。むしろ、セクション3.2.4.11で見つかったS-HTTPデフォルトが適用されます。
Two non-negotiation header lines for HTTP are defined here.
HTTPの2つの非交渉ヘッダーラインをここで定義します。
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 options headers.
すべてのS-HTTP準拠エージェントは、生成するすべてのHTTPメッセージのヘッダーにセキュリティスキームヘッダーを生成する必要があります。このヘッダーにより、他のエージェントがS-HTTP準拠エージェントと通信していることを検出し、適切な暗号オプションヘッダーを生成することができます。
For implementations compliant with this specification, the value must be 'S-HTTP/1.4'.
この仕様に準拠した実装の場合、値は「s-http/1.4」でなければなりません。
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：フィールドで提供された値を返すために使用されます。これは、カプセル化されたヘッダーに移動する必要があります。これにより、暗号化されたヘッダーが保護されています。
We describe here the special processing appropriate for client retries in the face of servers returning an error status.
ここでは、エラーステータスを返すサーバーに直面して、クライアントの再試行に適した特別な処理について説明します。
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の場合、サーバーが別の暗号化オプションセットを使用してクライアントがリクエストを再試行することをサーバーが期待することは考えられます（そして実際に可能性があります）。たとえば、クライアントが繰り返されているというアンカーを含むドキュメントは古く、問題のリクエストにデジタル署名を必要としませんでしたが、サーバーにはこの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.
これらのエラーに対するクライアントの応答における指針は、通常のアンカーの規制と同じように、これらのアンカーの控訴に関して、ユーザーに同じ種類の情報に基づいた選択を提供することです。たとえば、上記の場合、アクションの許可を要求せずにクライアントがリクエストに署名することは不適切です。
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 '、「Payment Required 402」は、HTTPスタイルの認証と支払いスキームの障害を表します。S-HTTPはこれらのメカニズムを明示的にサポートしていませんが、S-HTTPが提供するプライバシーサービスを利用しながら、S-HTTPで実行できます。（S-HTTP固有の認証エラーには他のエラーがあります。）
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リクエストが行われるべき場合にも使用されます。明らかに、これは元のリクエストが暗号化されるべきである場合にエラーを通知する以外に有用な目的を果たしませんが、他の状況（例：アクセス制御）が役立つ場合があります。
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リクエストとして行われた要求の場合、何らかの理由で要求に適用される暗号化の強化が不十分であり、応答ヘッダーにあるオプションでリクエストを繰り返す必要があることを示しています。これは、使用中のセッションキーが期限切れになった場合、またはリクエストの新鮮さを確保するために独自のNonCEを提供する場合、新しい公開キーの交渉を強制する方法として使用できることに注意してください。
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と応答ヘッダーに示されている暗号化オプションを使用してリクエストを再試行する必要があることを示します。
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
421 Bogusheaderコンテンツプリバシードメインを指定する必要があります
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応答に類似しています。
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.
この応答コードは、プロキシがリクエストのS-HTTPヘッダーにIF修飾シーンヘッダーを配置したプロキシサーバーインタラクションで使用するためのものです。この応答は、次の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の場合と同じ処理を実行することに注意してください。）
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の意味でリダイレクトする必要があります。
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が許容できること、およびリクエストが暗号化され、アンカーが参照されることを確認します。攻撃者はサーバーの返信を傍受し、移動した301ヘッダーを含むクライアントの公開キーの下に暗号化されたメッセージで応答します。クライアントがこのリダイレクトを自動的に実行する場合、ユーザーのクレジットカードの妥協が可能になります。
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. 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.
これは網羅的なリストではありませんが、ブラウザの著者は、他のケースで自動再閉鎖を実装する前に慎重に検討することをお勧めします。自動再結晶が適切でない場合の適切な動作は、許可を求めてユーザーを照会することであることに注意してください。
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.
通常のケースでさえ自動（ユーザー確認なしで）署名し、上記の危険性を考えると、署名の象徴を自動的に再試行することは禁止されているためです。
Assuming that all the other conditions are followed, it is permissible to automatically retry MAC authentication.
他のすべての条件が守られていると仮定すると、Mac認証を自動的に再試行することが許可されます。
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.
保護する必要があるクリアでリクエストを受信するサーバーは、必要なプライバシー強化を示すようにヘッダーラインを設定して「SecurityRetry 420」を返す必要があります。
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」を定義します。アンカーURLの一部としてこの指定子を使用すると、ターゲットサーバーがS-HTTP対応であり、このURLの逆方向がS-HTTP処理を受けることを意味します。
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 Obliviousエージェントは、未知のプロトコル仕様を使用してURLを繰り返すことをいとわないでください。したがって、感度の高いデータは、非安全なクライアントのユーザーが明確に誤って送信しないことに注意してください。
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.
安全なメッセージを準備しながら、ブラウザはトランザクションのセキュリティの視覚的な兆候と、メッセージを読むことができるパーティーの兆候を提供する必要があります。署名付きおよび/または包括的なメッセージを読んでいる間、ブラウザはこれを示し、署名者の身元を（該当する場合）示す必要があります。自己署名証明書は、認証階層によって検証された証明書と明確に区別される必要があります。
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メッセージの認証または復号化の失敗は、ドキュメントの取得の失敗とは異なる方法で提示する必要があります。準拠したクライアントは、オプションで検証できないドキュメントを表示する場合がありますが、検証可能な署名を持つデジタル署名またはドキュメントを所有していないドキュメントを表示する方法とは明確に異なる方法で、それらが明確に異なることを明確に示す必要があります。
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リクエストが署名されることを決定し、どの（多くのことがあると仮定して）署名に使用するかを決定する方法を提供するものとします。ユーザーには、デフォルトを選択する可能性のあるある種の選択リストが提示されることをお勧めします。ある種の明示的なユーザーインターフェイスアクションなしでは署名を実行する必要はありませんが、そのようなアクションはユーザー設定メカニズムを介して永続的な設定の形をとる可能性があります（これは落胆しますが）。
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および証明書チェーンを参照する方法を提供するものとします。これは、アンカーを含むドキュメントに署名した人を表示する方法とは異なるはずです。これらは暗号化情報の直交断片であるためです。
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は常にPreenhancedドキュメントをサポートしていますが、以前のバージョンでは、実際に実装する方法を明確にしていませんでした。このセクションでは、そのための2つの方法について説明します。HTTPリクエスト/応答の実現と、基礎となるデータの実現。
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ベースの）認証に適用される場合があります。
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).
複数のクライアントに同じコンテンツを繰り返し提供するサーバーの場合を考えてください。そのような例の1つは、カタログまたは価格表を提供するサーバーです。明らかに、顧客はこれらが実際の価格であることを確認できるようにしたいと考えています。ただし、価格は通常、すべてのコマーと同じであるため、機密性は問題ではありません。（注：このケースにも対処する方法については、以下のセクション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.
その結果、サーバーはドキュメントに一度署名し、クライアントが新しいリクエストを行うときにキャッシュされた署名ドキュメントを送信するだけで、毎回秘密鍵操作のオーバーヘッドを避けてください。おそらく、署名されたドキュメントはサードパーティによって生成され、サーバーのキャッシュに入れられた可能性があることに注意してください。サーバーには署名キーさえないかもしれません！これは、処方のセキュリティ利益を示しています。信頼されていないサーバーは、サーバーが侵害されていても、リスクなしに認証されたデータを提供できます。
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.
明らかな実装は、単に単一のリクエスト/応答を実行し、キャッシュし、新しいメッセージが生成される状況でそれを送信することです。
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を使用して基礎となるデータに署名し、S-HTTPの混乱として送信することも可能です。これを行うには、署名されたドキュメント（CMSまたはMOSSメッセージ）を取得し、両方のS-HTTPヘッダー（たとえば、S-HTTPリクエスト/応答ライン、コンテンツプリバシードメイン）と必要なHTTPヘッダー（内部コンテンツを反映するコンテンツタイプを含む）。
SECURE * Secure-HTTP/1.4
Content-Type: text/html
Content-Privacy-Domain: CMS
Random signed message here...
ここでランダムな署名されたメッセージ...
This message itself cannot be sent, but needs to be recursively encapsulated, as described in the next section.
このメッセージ自体を送信することはできませんが、次のセクションで説明するように、再帰的にカプセル化する必要があります。
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
Secure * Secure-HTTP/1.4 Content-Type：Application/S-HTTP Content-Privacy-Domain：CMS
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.
このアプローチは、ノンセがリクエストに含まれている場合、ドキュメントデータの非表現を提供しながら、サーバーアクティビティの新鮮さ（ドキュメント自体ではありませんが）を提供するためにも使用できることに注意してください。
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].
PreenHancementは署名で最適に機能しますが、特定の条件下で暗号化で使用することもできます。同じ機密文書を繰り返し送信する状況を考えてください。暗号化に費やす時間は、暗号文をキャッシュし、各受信者に新しいキー交換ブロックを生成するだけで保存できます。[これは、モスとCMSの両方で定義されているマルチレシピエントメッセージに論理的に同等であるため、RSAが使用されている場合は、適切なPKCS-1パディングを使用するように注意する必要があります。攻撃[HAST96]。
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サービスを使用できる必要があります。このセクションでは、上記のメカニズムを使用してこれらの目標を達成する方法について説明します。
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 Awareプロキシがリクエスト（HTTPまたはS-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の応答コードを受信すると、プロキシが送信した暗号化オプションを読み取り、メッセージにその拡張を適用する意思があるかどうかを判断する必要があります。クライアントがこれらの要件を満たす意思がある場合、適切なオプションを使用して以前に送信したリクエストを再帰的にカプセル化する必要があります。（拡張機能が再帰的に適用されるため、Clearのサーバーにリクエストを送信したくないクライアントでさえ、さらに暗号化せずに既に暗号化されたメッセージをプロキシに送信することをいとわない場合があることに注意してください。）カプセル化されたメッセージ）
When the proxy receives such a message, it should strip the outer encapsulation to recover the message which should be sent to the server.
プロキシがそのようなメッセージを受信したら、外側のカプセル化を除去して、サーバーに送信するメッセージを回復する必要があります。
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エージェントは、アウトバンド、INBAND、およびDHキーエクスチェンジをサポートする必要があります。
All agents must support encryption using DES-CBC.
すべてのエージェントは、DES-CBCを使用して暗号化をサポートする必要があります。
Agents must support signature generation and verification using NIST-DSS.
エージェントは、NIST-DSSを使用して署名の生成と検証をサポートする必要があります。
We present below a summary of the main syntactic features of S-HTTP/1.4, excluding message encapsulation proper.
S-HTTP/1.4の主要な構文機能の概要を以下に示します。
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>
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>
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>
Secure * Secure-HTTP/1.4
SECURE * SECUER-HTTP/1.4
Secure-HTTP/1.4 200 OK SecurityRetry 420 BogusHeader 421 <reason>
secure-http/1.4 200 ok securityretry 420 bogusheader 421 <理由>
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リクエストと返信の不自然な例を提供します。サンプルメッセージトレースから物語を引き立てるために、等しい標識の行が使用されます。実際の暗号化または署名されたメッセージ本文は、通常バイナリガベージであることに注意してください。（ほとんど）本物のメッセージを使用しながら読みやすさを維持するために、リクエストの本文はbase64エンコードされています。実際のS-HTTPメッセージを再生するには、メッセージ本文からbase64エンコードを削除する必要があります。
Alice, using an S-HTTP-capable client, begins by making an HTTP request which yields the following response page:
Aliceは、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==
Encryption-Identity: DN-1779, null, CN=Setec Astronomy, OU=Persona
Certificate,O="RSA Data Security, Inc.", C=US;
SHTTP-Privacy-Enhancements: recv-required=encrypt
<A name=tag1 HREF="shttp://www.setec.com/secret">
Don't read this. </A>
============================================================
An appropriate HTTP request to dereference this URL would be:
このURLの控除に対する適切なHTTP要求は次のとおりです。
============================================================
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
============================================================
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リクエストにはなかったであろう追加のキーアサイン行は、ボブ（サーバー）がアリスへの返信を暗号化することを許可しています。ボブによって。このリクエストには、次のS-HTTPカプセル化があります。
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
Content-Privacy-Domain: CMS
MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBqQIBADBTME0xCzAJBgNVBAYTAlVTMSAw
HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29u
YSBDZXJ0aWZpY2F0ZQICALYwDQYJKoZIhvcNAQEBBQAEQCU/R+YCJSUsV6XLilHG
cNVzwqKcWzmT/rZ+duOv8Ggb7oO/d8H3xUVGQ2LsX4kYGq2szwj8Q6eWhsmhf4oz
lvMAADCABgkqhkiG9w0BBwEwEQYFKw4DAgcECFif7BadXlw3oIAEgZBNcMexKe16
+mNxx8YQPukBCL0bWqS86lvws/AgRkKPELmysBi5lco8MBCsWK/fCyrnxIRHs1oK
BXBVlsAhKkkusk1kCf/GbXSAphdSgG+d6LxrNZwHbBFOX6A2hYS63Iczd5bOVDDW
Op2gcgUtMJq6k2LFrs4L7HHqRPPlqNJ6j5mFP4xkzOCNIQynpD1rV6EECMIk/T7k
1JLSAAAAAAAAAAAAAA==
============================================================
The data between the delimiters is a CMS message, RSA enveloped for Setec Astronomy.
デリミター間のデータはCMSメッセージで、RSAはSetec Astronomyに包まれています。
Bob decrypts the request, finds the document in question, and is ready to serve it back to Alice.
ボブはリクエストを復号化し、問題のドキュメントを見つけ、アリスに戻す準備ができています。
An appropriate HTTP server response would be:
適切なHTTPサーバーの応答は次のとおりです。
============================================================
HTTP/1.0 200 OK
Security-Scheme: S-HTTP/1.4
Content-Type: text/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>
============================================================
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
MIAGCSqGSIb3DQEHBqCAMIACAQAwgAYJKoZIhvcNAQcBMBEGBSsOAwIHBAifqtdy
x6uIMYCCARgvFzJtOZBn773DtmXlx037ck3giqnV0WC0QAx5f+fesAiGaxMqWcir
r9XvT0nT0LgSQ/8tiLCDBEKdyCNgdcJAduy3D0r2sb5sNTT0TyL9uydG3w55vTnW
aPbCPCWLudArI1UHDZbnoJICrVehxG/sYX069M8v6VO8PsJS7//hh1yM+0nekzQ5
l1p0j7uWKu4W0csrlGqhLvEJanj6dQAGSTNCOoH3jzEXGQXntgesk8poFPfHdtj0
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)
DES-DECRYPT（INBAND：1,697FA820DF8A6E53）
where 'inband:1' is the key exchanged in the Key-Assign line in the original request.
ここで、 'inband：1'は、元のリクエストのキーアサイン行で交換されるキーです。
There is a link on the HTML page that was just returned, which Alice dereferences, creating the HTTP message:
HTMLページには返されたばかりのリンクがあります。これは、Aliceの拒否を繰り返し、HTTPメッセージを作成します。
============================================================
GET /prize.html HTTP/1.0
Security-Scheme: S-HTTP/1.4
User-Agent: Web-O-Vision 1.1beta
Accept: *.*
============================================================
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
MIAGCSqGSIb3DQEHAaCABGNHRVQgL3ByaXplLmh0bWwgSFRUUC8xLjAKU2VjdXJp
dHktU2NoZW1lOiBTLUhUVFAvMS4xClVzZXItQWdlbnQ6IFdlYi1PLVZpc2lvbiAx
LjFiZXRhCkFjY2VwdDogKi4qCgoAAAAA
============================================================
The data between the delimiters is a CMS 'Data' representation of the request.
デリミター間のデータは、リクエストのCMS「データ」表現です。
Appendix: A Review of CMS
付録：CMSのレビュー
CMS ("Cryptographic Message Syntax Standard") is a cryptographic message encapsulation format, similar to PEM, based on RSA's PKCS-7 cryptographic messaging syntax.
CMS（「暗号化メッセージ構文標準」）は、RSAのPKCS-7暗号化メッセージング構文に基づいて、PEMと同様の暗号化メッセージカプセル化形式です。
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つにすぎませんが、交渉可能なオプションの最小限のセットを許可し、バイナリエンコーディングを許可するため、優先される必要があります。この仕様をより自己完結型にするために、ここで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の抽象的構文表記（X.208で定義されているASN.1）の観点から定義され、ASN.1の基本エンコードルール（BER、X.209で定義）を使用して具体的に表されます。CMSメッセージは、入力されたコンテンツパーツのシーケンスです。6つのコンテンツタイプがあり、再帰的に構成可能です。
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つ以上の（受信者ごと）キーエクスチェンジブロックと暗号化されたコンテンツパーツ。
DigestedData -- A content part with a single digest block.
DigestedData-単一のダイジェストブロックを備えたコンテンツパーツ。
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)
DigestedData = DigestAlg Content DigestBytes
EncryptedData = BulkCryptAlg Encrypted(Bytes)
SignerInfo = CertID ... Encrypted(DigestBytes) ...
RecipientInfo = CertID KeyCryptAlg Encrypted(DEK)
Appendix: Internet Media Type message/s-http
付録：インターネットメディアタイプメッセージ/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
メディアタイプ名：メッセージメディアサブタイプ名：s-http必要パラメーター：なしオプションパラメーター：バージョン、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] Bellare、M.、Canetti、R.、Krawczyk、H。、「メッセージ認証のためのキーハッシュ機能」、Preprint。
[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 Pub）46-1、データ暗号化標準、1988年1月22日の再確認（Supersedes Fips Pub 46、1977年1月15日）。
[FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
[FIPS-81]連邦情報処理標準出版（FIPS Pub）81、DES Modes of Operation、1980 12月2日。
[FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17.
[FIPS-180]連邦情報処理標準出版（FIPS Pub）180-1、「Secure Hash Standard」、1995年4月17日。
[FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 1994 May 19.
[FIPS-186]連邦情報処理標準出版（FIPS Pub）186、Digital Signature Standard、1994年5月19日。
[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、J。、「公開キーネットワークでの指数が低いRSAを使用すると、Cryptology-Crypto 95 Proceedings、Springer-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] Johnson、D.B.、Matyas、S.M.、Le、A.V.、Wilkins、J.D。、「コマーシャルデータマスキング施設データプライバシーアルゴリズムのデザイン」Proceedings 1st ACM Conference on Computer＆Communications Security、1993年11月、フェアファックス、バージニア州、pp。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] Lai、X。「ブロック暗号の設計とセキュリティについて」、情報処理のETHシリーズ、v。1、Konstanz：Hartung-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.
[CMS] Housley、R。、「暗号化メッセージの構文」、RFC 2630、1999年6月。
[RFC-822] Crocker, D., "Standard For The Format Of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[RFC-1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.
[RFC-1319] Kaliski、B。、「The MD2 Message-Digest Algorithm」、RFC 1319、1992年4月。
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC-1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、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] Linn、J。、「インターネット電子メールのプライバシー強化：パートI：メッセージ暗号化と認証手順」、RFC 1421、1993年2月。
[RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.
[RFC-1422] Kent、S。、「インターネット電子メールのプライバシー強化：パートII：証明書ベースのキー管理」、RFC 1422、1993年2月。
[RFC-1779] Kille, S., "A String Representation of Distinguished Names", RFC 1779, March 1995.
[RFC-1779] Kille、S。、「著名な名前の文字列表現」、RFC 1779、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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1993年9月。
[RFC-1738] T. Berners-Lee, "Uniform Resource Locators (URLs)", RFC 1738, December 1994.
[RFC-1738] T. Berners-Lee、「Uniform Resource Locators（URLS）」、RFC 1738、1994年12月。
[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] Galvin、J.、Murphy、S.、Crocker、S.、およびN. Freed、「MultiPart/Signed and MultiPart/暗号化」、RFC 1847、1995年10月。
[RFC-1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME Object Security Services", RFC 1848, October 1995.
[RFC-1848] Crocker、S.、Freed、N.、Galvin、J。、およびS. Murphy、「Mime Object Security Services」、RFC 1848、1995年10月。
[RFC-1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[RFC-1864] Myers、J。およびM. Rose、「The Content-MD5ヘッダーフィールド」、RFC 1864、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、 "HyperText Transfer Protocol-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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、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. Canetti、「HMAC：Keyed Hashing for Message Authentication」、RFC 2104、1997年2月。
[SHTML] Rescorla, E. and A. Schiffman, "Security Extensions For HTML", RFC 2659, August 1999.
[Shtml] Rescorla、E。およびA. Schiffman、「HTMLのセキュリティ拡張」、RFC 2659、1999年8月。
[VANO95] B. Prennel and P. van Oorschot, "On the security of two MAC algorithms", to appear Eurocrypt'96.
[vano95] B.プレンネルとP.ヴァンオーショット、「2つのMacアルゴリズムのセキュリティについて」、EuroCrypt'96を表示します。
[X509] CCITT Recommendation X.509 (1988), "The Directory - Authentication Framework".
[X509] CCITT推奨X.509（1988）、「ディレクトリ - 認証フレームワーク」。
Security Considerations
セキュリティに関する考慮事項
This entire document is about security.
このドキュメント全体はセキュリティに関するものです。
Authors' Addresses
著者のアドレス
Eric Rescorla RTFM, Inc. 30 Newell Road, #16 East Palo Alto, CA 94303
Eric Rescorla RTFM、Inc。30 Newell Road、＃16 East Palo Alto、CA 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.シフマンスピルス/テリサ5303ベッツィーロスドライブサンタクララ、カリフォルニア95054
Phone: (408) 327-1901 EMail: ams@terisa.com
電話：（408）327-1901メール：ams@terisa.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。