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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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の基礎を形成するハイパーテキスト転送プロトコル（HTTP）を使用して送信されたメッセージを確保するための構文について説明します。セキュアHTTP（S-HTTP）は、トランザクションの機密性、信頼性/完全性と起源の非repudiabilityのために独立して適用可能なセキュリティサービスを提供します。
The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction.
プロトコルは、各トランザクションのために当事者間のオプションのネゴシエーションをサポートすることにより、鍵管理の仕組み、セキュリティポリシーと暗号化アルゴリズムの選択に最大限の柔軟性を強調しています。
Table of Contents
目次
1. Introduction .................................................. 3
1.1. Summary of Features ......................................... 3
1.2. Changes ..................................................... 4
1.3. Processing Model ............................................ 5
1.4. Modes of Operation .......................................... 6
1.5. Implementation Options ...................................... 7
2. Message Format ................................................ 7
2.1. Notational Conventions ...................................... 8
2.2. The Request Line ............................................ 8
2.3. The Status Line ............................................. 8
2.4. Secure HTTP Header Lines .................................... 8
2.5. Content .....................................................12
2.6. Encapsulation Format Options ................................13
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.
ワールド・ワイド・ウェブ（WWW）は、インターネットユーザーの間で広く受け入れられており、分散ハイパーメディアシステムです。 WWWブラウザは、インターネットアプリケーションプロトコルを既存の、他のサポートしていますが、WWWクライアントとサーバ間で使用されるネイティブおよび主要プロトコルは、ハイパーテキスト転送プロトコル（HTTP）[RFC-2616]です。ウェブの使いやすさは、多くのアプリケーションのためのクライアント/サーバ・アーキテクチャとその広範な雇用を求めています。そのような多くのアプリケーションが相互に認証し、内密に機密情報を交換できるようにするには、クライアントとサーバーを必要としています。元のHTTP仕様では、このような取引のための適切な暗号化メカニズムのための唯一のささやかなサポートを持っていました。
Secure HTTP (S-HTTP) provides secure communication mechanisms between an HTTP client-server pair in order to enable spontaneous commercial transactions for a wide range of applications. Our design intent is to provide a flexible protocol that supports multiple orthogonal operation modes, key management mechanisms, trust models, cryptographic algorithms and encapsulation formats through option negotiation between parties for each transaction.
セキュアHTTP（S-HTTP）は、アプリケーションの広い範囲のために自発的商取引を可能にするために、HTTPクライアント - サーバ対間の安全な通信メカニズムを提供します。当社の設計意図は、各トランザクションの当事者間のオプションのネゴシエーションを介して複数の直交の動作モードをサポートする柔軟なプロトコル、鍵管理の仕組み、信頼モデル、暗号化アルゴリズムおよびカプセル化フォーマットを提供することです。
Secure HTTP is a secure message-oriented communications protocol designed for use in conjunction with HTTP. It is designed to coexist with HTTP's messaging model and to be easily integrated with HTTP applications.
セキュアHTTPは、HTTPと組み合わせて使用するために設計され、安全なメッセージ指向の通信プロトコルです。 HTTPのメッセージングモデルと共存するために、簡単にHTTPアプリケーションと統合できるように設計されています。
Secure HTTP provides a variety of security mechanisms to HTTP clients and servers, providing the security service options appropriate to the wide range of potential end uses possible for the World-Wide Web. The protocol provides symmetric capabilities to both client and server (in that equal treatment is given to both requests and replies, as well as for the preferences of both parties) while preserving the transaction model and implementation characteristics of HTTP.
セキュアHTTPは、潜在的な終わりの広い範囲のワールド・ワイド・ウェブのための可能な使用に適切なセキュリティサービスオプションを提供し、HTTPクライアントとサーバにセキュリティメカニズムを数多く提供しています。 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.
いくつかの暗号メッセージ・フォーマット規格は特に、原理的には、[CMS]と[MOSS]に限定されるものではなく、S-HTTPクライアントとサーバ、に組み込むことができます。 S-HTTPは、実装の様々な間の相互運用をサポートし、HTTPと互換性があります。このような取引は明らかにS-HTTPのセキュリティ機能を使用することはありませんが、S-HTTP対応クライアントは、S-HTTP忘れサーバおよびその逆と通信することができます。
S-HTTP does not require client-side public key certificates (or public keys), as it supports symmetric key-only operation modes.
それは対称鍵のみの動作モードをサポートしてS-HTTPは、クライアント側の公開鍵証明書（公開鍵など）を必要としません。
This is significant because it means that spontaneous private transactions can occur without requiring individual users to have an established public key. While S-HTTP is able to take advantage of ubiquitous certification infrastructures, its deployment does not require it.
それは自発的な民間取引が確立した公開鍵を持っている個々のユーザーを必要とせずに発生する可能性があることを意味するので、これは重要です。 S-HTTPは、ユビキタス認証インフラを活用することが可能ですが、その展開は、それを必要としません。
S-HTTP supports end-to-end secure transactions, in contrast with the original HTTP authorization mechanisms which require the client to attempt access and be denied before the security mechanism is employed. Clients may be "primed" to initiate a secure transaction (typically using information supplied in message headers); this may be used to support encryption of fill-out forms, for example. With S-HTTP, no sensitive data need ever be sent over the network in the clear.
S-HTTPアクセスを試みることと、セキュリティ・メカニズムが採用される前に拒否されたクライアントを必要と元HTTP認証メカニズムとは対照的に、エンド・ツー・エンドの安全なトランザクションをサポートしています。クライアントは、（典型的には、メッセージヘッダーに提供された情報を使用して）安全なトランザクションを開始するために「下塗りされた」ことができます。これは、たとえば、フィル・アウト形式の暗号化をサポートするために使用することができます。 S-HTTPを使用すると、機密データは、これまで明らかにネットワーク経由で送信されることが必要ありません。
S-HTTP provides full flexibility of cryptographic algorithms, modes and parameters. Option negotiation is used to allow clients and servers to agree on transaction modes (e.g., should the request be signed or encrypted or both -- similarly for the reply?); cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypting, etc.); and certificate selection (please sign with your "Block-buster Video certificate").
S-HTTPは、暗号化アルゴリズム、モード及びパラメータの完全な柔軟性を提供します。オプションのネゴシエーションは（？例えば、リクエストが署名または暗号化、またはその両方する必要があります - 同様に、返信用）クライアントとサーバは、トランザクション・モードに同意することを可能にするために使用されます。暗号アルゴリズム（署名のためのDSA対RSA、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について説明します。それは暗号メッセージ構文（CMS）[CMS]、PKCS-7の後継の支援で前メモとは異なるという点で、以前のメモは異なります。従って今ディフィ - ヘルマン及び（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メッセージの作成は、三つの入力の関数と考えることができます。
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メッセージまたはいくつかの他のデータオブジェクトのいずれかです。平文メッセージを透過的に行われるため、ヘッダとすべては、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つの鍵転送メカニズムを定義し、公開鍵を用いたものは、鍵交換及び外部に配置されたキーを持つ別のエンベロープ。
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.
後者のモードでは、ヘッダ行のいずれかに指定された鍵識別情報と、事前に決められたセッション鍵を用いてコンテンツを暗号化します。
Secure HTTP provides a means to verify message integrity and sender authenticity for a message via the computation of a Message Authentication Code (MAC), computed as a keyed hash over the document using a shared secret -- which could potentially have been arranged in a number of ways, e.g.: manual arrangement or 'inband' key management. This technique requires neither the use of public key cryptography nor encryption.
潜在的に多数に配置されている可能性 - 安全なHTTPは、共有秘密を使用して文書上鍵付きハッシュとして計算され、メッセージ認証コード（MAC）の計算を介してメッセージのメッセージ完全性と送信者の真正性を検証する手段を提供しますいくつかの方法、例えば：手動配置や「インバンド」キー管理。この技術は、公開鍵暗号方式や暗号化の使用も必要としません。
This mechanism is also useful for cases where it is appropriate to allow parties to identify each other reliably in a transaction without providing (third-party) non-repudiability for the transactions themselves. The provision of this mechanism is motivated by our bias that the action of "signing" a transaction should be explicit and conscious for the user, whereas many authentication needs (i.e., access control) can be met with a lighter-weight mechanism that retains the scalability advantages of public-key cryptography for key exchange.
この機構はまた、当事者がトランザクション自身のために（サードパーティ）非repudiabilityを設けることなく、トランザクションに確実にお互いを識別することを可能にすることが適切である場合に有用です。このメカニズムの規定は、取引「署名」のアクションは、ユーザーの明示的かつ意識する必要があることを私達のバイアスによって動機づけされ、多くの認証ニーズ（すなわち、アクセス制御）を保持軽量な機構を満たすことができるのに対し、鍵交換のための公開鍵暗号のスケーラビリティの利点。
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メッセージのヘッダー許容。
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.
アプリケーション要件、ユーザーの高度化の変動、および異種の実装上の制約の広い範囲に直面してワールド・ワイド・ウェブのためのセキュアな文書の普及を奨励するために、セキュア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メッセージを区別し、特別な処理を可能にするために、特別なセキュアな「方法とプロトコル指定子を使用して 『使用すべき要求ラインは、セキュアHTTP / 1.4』となるため、セキュアHTTPおよびHTTP処理することができます。たとえば、「*」である必要があり、潜在的な機密情報のRequest-URIの漏洩を防止するために、例えばポート80、同じTCPポート上で混在：
Secure * Secure-HTTP/1.4
セキュア*セキュア-HTTP / 1.4
When communicating via a proxy, the Request-URI should be consist of
the AbsoluteURI. Typically, the rel path section should be replaced
by "*" to minimize the information passed to in the clear. (e.g.
http://www.terisa.com/*); proxies should remove the appropriate
amount of this information to minimize the threat of traffic
analysis. See Section 7.2.2.1 for a situation where providing more
information is appropriate.
S-HTTP responses should use the protocol designator "Secure-HTTP/1.4". For example:
S-HTTP応答はプロトコル指定子 "セキュアHTTP / 1.4" を使用する必要があります。例えば：
Secure-HTTP/1.4 200 OK
セキュア-HTTP / 1.4 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メッセージのヘッダーに行きます。すべての 'Content-Typeの' と 'のContent-プライバシー-DOMAIN' を除いてオプションです。メッセージの本体は、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リクエスト/レスポンス・ライン以下と「S-HTTPヘッダー」として集合的に連続のCRLFに先行するヘッダブロックを指します。
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つの値は、「MOSS」と「CMS」です。 CMSは、セクション2.6.1で指定されたプライバシーの強化を指します。 MOSSは、[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のラインの読みがなければなりません。
Content-Type: message/http
Content-Type：メッセージ/ 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.
端末コンテンツタイプが適切に適切なContent-Typeヘッダラインを用いて示されていることを条件とするいくつかの他のタイプであってもよいです。この場合には、端末コンテンツのカプセル化のためのヘッダフィールドは、端末コンテンツ（「最終ヘッダー」）に適用します。該当するS-HTTP / HTTPヘッダが非造影渡されることはありませんように、しかし、いずれにしても、最終的にヘッダ自体が常にS-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ヘッダーことを必要とせずに、事前拡張データ（特にpresignedデータ）を通過するのに有用なメカニズムです。
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用のContent-Typeを適用した暗号処理を説明的に許容されるMIMEコンテンツタイプでなければなりません。 （例えば、マルチパート/署名されました）。インナーコンテンツのコンテンツ・タイプは、その内側のコンテンツに対応するコンテンツタイプ行に記載されており、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つの用途は、当事者の一方が鍵ペアを持っていない場合には、戻り暗号化のためのセッションキーのインバンド通信を可能にすることです。しかし、これはまた、当事者が、例えば、ワンタイムキーのリストを他のいくつかのメカニズムを使用することを選択した場合に有用です。
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つのメソッドを定義します。インバンドは、セッション鍵は、対応する方法のキー割り当てヘッダを使用して、以前に交換されたことを示しています。帯域外構成は、エージェントは、おそらくデータベースアクセスを介して、指定された名前に対応する鍵材料への外部アクセスを持っているか、おそらくキーボード入力からユーザが直ちに供給されることを意味します。ヘッダ行の構文は次のとおりです。
Prearranged-Key-Info = "Prearranged-Key-Info" ":" Hdr-Cipher "," CoveredDEK "," CoverKey-ID CoverKey-ID = method ":" key-name CoveredDEK = *HEX method = "inband" | "outband"
予定-キー情報は= "予定-キー情報" "：" HDR-暗号 "" CoveredDEK "" CoverKey-ID CoverKey-ID =法 "：" キー名CoveredDEK = * HEX方法= "インバンド" | 「帯域外」
While chaining ciphers require an Initialization Vector (IV) [FIPS-81] to start off the chaining, that information is not carried by this field. Rather, it should be passed internal to the cryptographic format being used. Likewise, the bulk cipher used is specified in this fashion.
連鎖暗号がチェーンを始めるために初期化ベクトル（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暗号>は、セッション鍵を暗号化するために使用されるブロック暗号の名前でなければならない（セクション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.
<CoveredDEK>カプセル化されたメッセージが暗号化されたの下で保護されたデータ暗号化キー（別称、トランザクションキー）です。これは、適切に（ランダムに）示されたヘッダ暗号を使用して、その後ネゴシエートキー（別名セッション鍵）のカバーの下で暗号化された送信エージェントによって生成され、次いでヘクスに変換すべきです。
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.
MOSSと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>))
MAC =ヘキサ（H（メッセージ|| [<時間>] || <共有鍵>））
The time should be represented as an unsigned 32 bit quantity representing seconds since 00:00:00 GMT January 1, 1970 (the UNIX epoch), in network byte order. The shared key format is a local matter.
時間は、ネットワークバイト順で、00:00:00 GMT 1970年1月1日（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を参照）の新シリーズをご紹介します。 （^ビット単位のXORを意味します）
HMAC = hex(H(K' ^ pad2 || H(K' ^ pad1 ||[<time>]|| Message))) pad1 = the byte 0x36 repeated enough times to fill out a hash input block. (I.e. 64 times for both MD5 and SHA-1) pad2 = the byte 0x5c repeated enough times to fill out a hash input block. K' = H(<shared key>)
HMAC =ヘキサ（H（K '^ PAD2 || H（K' ^ PAD1 || [<時間>] ||メッセージ）））PAD1 =バイト0x36は、ハッシュ入力ブロックを満たすのに十分な回数繰り返します。 PAD2（MD5とSHA-1の両方のための、すなわち64回）=バイトコードに5Cは、ハッシュ入力ブロックを満たすのに十分な回数繰り返します。 K」= H（<共有鍵>）
The original HMAC construction is for the use of a key with length equal to the length of the hash output. Although it is considered safe to use a key of a different length (Note that strength cannot be increased past the length of the hash function itself, but can be reduced by using a shorter key.) [KRAW96b] we hash the original key
オリジナルHMAC構造はハッシュ出力の長さに等しい長さの鍵を使用するためのものです。異なる長さのキーを使用しても安全であると考えられているが（その強さは、ハッシュ関数自体の長さを超えて増加することはできませんが、短いキーを使用することにより低減することができます。）[KRAW96b]我々は元のキーをハッシュ
to permit the use of shared keys (e.g. passphrases) longer than the length of the hash. It is noteworthy (though obvious) that this technique does not increase the strength of short keys.
ハッシュの長さよりも長い共有キー（例えば、パスフレーズ）の使用を可能にします。この技術は短い鍵の強度を増加させないこと（明らかが）それは注目に値します。
The format of the MAC-Info line is:
MAC-インフォラインの形式は次のとおりです。
MAC-Info = "MAC-Info" ":" [hex-time], hash-alg, hex-hash-data, key-spec hex-time = <unsigned seconds since Unix epoch represented as HEX> hash-alg = <hash algorithms from section 3.2.4.8> hex-hash-data = <computation as described above represented as HEX> Key-Spec = "null" | "dek" | Key-ID
MAC-情報は= "MAC-情報" "：ハッシュ-ALG = <" の[hex-時間]、ハッシュ-ALG、六角ハッシュデータ、キースペック六角時間= <HEXとして表さUNIXエポック符号なし秒>ハッシュ・セクション3.2.4.8からアルゴリズム> HEX>キースペック=「NULL」として表され、上述のように六角ハッシュデータ= <計算| "DEK" |キーID
Key-Ids can refer either to keys bound using the Key-Assign header line or those bound in the same fashion as the Outband method described later. The use of a 'Null' key-spec implies that a zero length key was used, and therefore that the MAC merely represents a hash of the message text and (optionally) the time. The special key-spec 'DEK' refers to the Data Exchange Key used to encrypt the following message body (it is an error to use the DEK key-spec in situations where the following message body is unencrypted).
キーIdsはいずれかのキー割り当てヘッダ行又は後述の帯域外方法と同じ方法で結合したものを使用して結合し、キーを参照することができます。 「NULL」キー仕様の使用は、MACは、単にメッセージテキスト及び（任意に）時間のハッシュを表すことが長さゼロのキーが使用されたことを意味し、そして。特別なキースペック「DEKは、」データExchangeキーは（次のメッセージの本文が暗号化されていない状況でDEKキースペックを使用するとエラーになります）、次のメッセージ本体を暗号化するために使用を指します。
If the time is omitted from the MAC-Info line, it should simply not be included in the hash.
時間はMAC-インフォラインから省略されている場合、それは単にハッシュに含まれるべきではありません。
Note that this header line can be used to provide a more advanced equivalent of the original HTTP Basic authentication mode in that the user can be asked to provide a username and password. However, the password remains private and message integrity can be assured. Moreover, this can be accomplished without encryption of any kind.
ユーザーは、ユーザー名とパスワードの入力を求められることが可能という点で、このヘッダ行は、元のHTTP基本認証モードのより高度な同等のものを提供するために使用することができることに注意してください。ただし、パスワードはプライベートのままとメッセージの整合性を確保することができます。また、これはどのような種類の暗号化をすることなく達成することができます。
In addition, MAC-Info permits fast message integrity verification (at the loss of non-repudiability) for messages, provided that the participants share a key (possibly passed using Key-Assign in a previous message).
また、MAC-情報がメッセージを（非repudiabilityの損失で）高速のメッセージの完全性の検証を可能にし、（おそらく前のメッセージでキーの割り当てを使用して渡された）参加者が鍵を共有することを提供します。
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.
MOSSとCMSの一部のコンテンツプライバシー・ドメイン、特にそうな将来の改訂は、対称完全性保護たMAC-Infoフィールドのためのサポートを有していてもよく、このような状況で使用する必要はないことに注意してください。むしろ、ネイティブの構文が好ましいです。キーの割り当てと交換キーは、しかし、このような状況で使用することができます。
The content of the message is largely dependent upon the values of the Content-Privacy-Domain and Content-Transfer-Encoding fields.
メッセージの内容は、Content-プライバシードメインの値とContent-転送エンコードフィールドに大きく依存します。
For a CMS message, with '8BIT' Content-Transfer-Encoding, the content should simply be the CMS message itself.
CMSメッセージについては、「8BIT」コンテンツ転送エンコードで、コンテンツは単にCMSメッセージそのものである必要があります。
If the Content-Privacy-Domain is MOSS, the content should consist of a MOSS Security Multipart as described in RFC1847.
コンテンツプライバシードメインは、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リクエストであることが期待されます。代替的に、コンテンツがクリアコンテンツが得られるか、プライバシーの強化がもはや除去できなくなるまでプライバシーの強化をアンラップすべき場合には、別のセキュアHTTPメッセージであってもよいです。 （これは、シーケンシャル署名およびエンベロープ拡張などの拡張機能の埋め込みを可能にする。）は、すべての拡張機能を除去することができ、さもなければContent-Typeの線で指定しない限り、最終的な脱拡張コンテンツが有効な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).
コンテンツプライバシードメイン「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つの直交軸に進むことができます。任意のメッセージがいずれかの両方、またはどちらも、暗号化された署名することができます。それはDigestedData 'タイプをサポートしないがCMSは、「KeyDigestedData」タイプをサポートしていないので、S-HTTPの「認証」保護モードはセクション2.3.6のMAC-Infoヘッダを介して独立してCMSコーディングの設けられています。
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.
この拡張機能は、CMSの「のSignedData」タイプを使用しています。デジタル署名が使用される場合、適切な証明書は、いずれかの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の下で（「EnvelopedDataの」タイプのいずれかを使用して）包み込むように正確に行われます。メッセージは、この方法で暗号化された署名またはそれ以外の場合は、CMSの準拠しています。署名され、暗号化されたメッセージの両方を有するためには、単にCMSのSignedData生産を作成し、CMSに記載されているようにEnvelopedDataでそれをカプセル化します。
This uses the 'EncryptedData' type of CMS. In this mode, we encrypt the content using a DEK encrypted under cover of a prearranged session key (how this key may be exchanged is discussed later), with key identification information specified on one of the header lines. The IV is in the EncryptedContentInfo type of the EncryptedData element. To have a message which is both signed and encrypted, one simply creates the CMS SignedData production and encapsulates it in EncryptedData as described in CMS.
これは、CMSの「はEncryptedData」タイプを使用しています。このモードでは、ヘッダ行のいずれかに指定されたキーの識別情報を有する（交換されてもよい。このキーは後述する方法）予定セッションキーのカバーの下で暗号化されたDEKを用いてコンテンツを暗号化します。 IVは、EncryptedData要素のEncryptedContentInfoタイプです。署名され、暗号化されたメッセージの両方を有するためには、単にCMSのSignedData生産を作成し、CMSに記載されているようにはEncryptedDataでそれをカプセル化します。
The body of the message should be a MIME compliant message with content type that matches the Content-Type line in the S-HTTP headers. Encrypted messages should use multipart/encrypted. Signed messages should use multipart/signed. However, since multipart/signed does not convey keying material, is is acceptable to use multipart/mixed where the first part is application/mosskey-data and the second part is multipart/mixed in order to convey certificates for use in verifying the signature.
メッセージの本文には、S-HTTPヘッダー内のContent-Typeラインに一致するコンテンツの種類とMIME準拠したメッセージでなければなりません。暗号化されたメッセージはマルチパート/暗号化を使用する必要があります。署名されたメッセージはマルチパート/署名を使用する必要があります。最初の部分は、アプリケーション/ mosskeyデータであり、第2の部分は、署名を検証する際に使用するための証明書を伝達するために、混合/マルチパートである場合しかし、マルチ以降/キーイング材料を搬送しない署名/マルチ混合使用することが許容されています。
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.
ホストヘッダーは、要求されたリソースのインターネットホストとポート番号をspecificies。このヘッダは、このメッセージを解釈することができ、その中の複数の潜在的なセキュリティコンテキストのうち明確にするために使用されるべきです。開封されたHTTPメッセージは、それ自身のHostフィールドを持っていることに注意してください（これは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.
それはHTTPヘッダの場合と同様の接続フィールドは、S-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.
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:
ネゴシエーションヘッダは各詳細四部分スキーマに準拠する仕様の配列です。
Property -- the option being negotiated, such as bulk encryption
algorithm.
Value -- the value being discussed for the property, such as DES-CBC
値 - 値は、DES-CBCのように、プロパティに議論され
Direction -- the direction which is to be affected, namely: during reception or origination (from the perspective of the originator).
方向 - つまり、影響される方向：受信または発信中（発信者の観点から）。
Strength -- strength of preference, namely: required, optional, refused
強さ - 好みの強さ、すなわち：必須、オプション、拒否しました
As an example, the header line:
一例として、ヘッダ行：
SHTTP-Symmetric-Content-Algorithms: recv-optional=DES-CBC,RC2
SHTTP対称-コンテンツアルゴリズム：RECV-オプション= DES-CBC、RC2
could be thought to say: "You are free to use DES-CBC or RC2 for bulk encryption for encrypting messages to me."
言うことを考えることができます：「あなたは私にメッセージを暗号化するためのバルク暗号化にDES-CBCまたはRC2を自由に使用できます。」
We define new headers (to be used in the encapsulated HTTP header, not in the S-HTTP header) to permit negotiation of these matters.
私たちは、新しいヘッダがこれらの問題の交渉を許可する（ないS-HTTPヘッダーで、カプセル化されたHTTPヘッダーで使用される）を定義します。
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:
<モード>の値は、この<キー値>は、エージェントの行動がそれらを受信するとは対照的に、プライバシー強化されたメッセージを送信するとしている何を指しているかどうかを示します。任意の所与のモードアクションペアのために、解釈は、記載されている拡張機能（<値> 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-required:' The agent will not process messages without this enhancement.
「RECV-必要：」エージェントは、この拡張機能なしでメッセージを処理しません。
'recv-refused:' The agent will not process messages with this enhancement.
「RECV-拒否した：」エージェントは、この拡張機能でメッセージを処理しません。
'orig-optional:' When encountering an agent which refuses this enhancement, the agent will not provide it, and when encountering an agent which requires it, this agent will provide it.
「ORIG-オプション：」この拡張を拒否エージェントに遭遇すると、エージェントはそれを提供することはありません、それを必要とするエージェントに遭遇したとき、このエージェントはそれを提供します。
'orig-required:' The agent will always generate the enhancement.
「ORIG-必要：」エージェントは、常に向上を生成します。
'orig-refused:' The agent will never generate the enhancement.
「ORIG-拒否した：」エージェントは、エンハンスメントを生成することはありません。
The behavior of agents which discover that they are communicating with an incompatible agent is at the discretion of the agents. It is inappropriate to blindly persist in a behavior that is known to be unacceptable to the other party. Plausible responses include simply terminating the connection, or, in the case of a server response, returning 'Not implemented 501'.
彼らは互換性のないエージェントと通信していることを発見エージェントの動作は、エージェントの裁量です。盲目的に他の当事者に受け入れられないことが知られている行動に固執することは不適切です。もっともらしい応答は、単に接続を終了、または、サーバーの応答の場合には、「501を実装されていない」帰国含まれています。
Optional values are considered to be listed in decreasing order of preference. Agents are free to choose any member of the intersection of the optional lists (or none) however.
オプションの値は、優先順にリストされていると考えられます。エージェントは、しかし、オプションのリスト（またはnone）の交点の任意のメンバーを自由に選択できます。
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.
任意の<キーヴァル>は未定義のままにすると、デフォルトに設定されているものとする必要があります。エージェントが指定されているすべてのキーは、そのフィールドのデフォルトのいずれかの<キーヴァル>でそのキーのいずれかの外観を上書きしなければなりません。
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>']'
<暗号> '[' <bound1> ' - ' <bound2> ']'
For purposes of preferences, this notation should be treated as if it read (assuming x and y are integers)
それが読み取るかのように好みの目的のために、この表記は（xおよびyは整数であると仮定して）処理しなければなりません
<cipher>[x], <cipher>[x+1],...<cipher>[y] (if x<y)
<暗号> [X]、<暗号> [X + 1]、... <暗号> [Y]（IF X <Y）
and
そして
<cipher>[x], <cipher>[x-1],...<cipher>[y] (if x>y)
<暗号> [X]、<暗号> [X-1]、... <暗号> [Y]（もしX> Y）
The special value 'inf' may be used to denote infinite length.
特別な値「INF」は無限の長さを示すために使用されてもよいです。
Using simply <cipher> for such a cipher shall be read as the maximum range possible with the given cipher.
そのような暗号化のために単に<暗号>を使用することは、所与の暗号化で可能な最大範囲と読み替えるものとします。
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のコンテンツプライバシードメイン型を意味します。許容値は、などが記載されています。例えば、
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」、「帯域外」と「インバンド」です。 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 - 暗号ブロック連鎖（CBC）モードでのDES [FIPS-81] DES-EDE-CBC - 2キー3DES外側のCBCモードのDES-EDE3-CBCで暗号化 - 復号化 - 暗号化を使用して、 - 使用して3キー3DES暗号化・復号化・暗号化アウタCBCモードDESX-CBCに - CBCモードIDEA-CBCにおけるRSAのDESX - CBCモードRC2-CBCにIDEA - CBCモードCDMF-CBCにおけるRSAのRC2 - IBMのCDMF（弱化キーDES） 【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 - ECBモードのDES-EDE3-ECBに暗号化 - 復号化 - 暗号化を使用して2キー3DES - - 3キー3DESをEncrypt-を用いた電子コードブック内のDES（ECB）モード[FIPS-81] DES-EDE、ECB ECBモードDESX-ECBに-暗号化は、解読 - RSAのDESXは、ECBモードIDEA-ECBに - IDEA RC2-ECB - ECBモードCDMF-ECBにおけるRSAのRC2 - IBMのCDMF ECBモードで
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の予定-キー情報の構文を使用して、トランザクションキーの暗号化に使用するキー名のために必要な値を指定します。パターン情報の構文は、正規表現をコンマで区切った一連の構成されています。彼らは正規表現で表示された場合にコンマはバックスラッシュでエスケープする必要があります。最初のパターンが最も好適であると仮定されるべきです。
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.
認証キーパターンは、MAC認証者のための使用を希望する名前の形式を指定します。パターン情報の構文は、正規表現をコンマで区切った一連の構成されています。彼らは正規表現で表示された場合にコンマはバックスラッシュでエスケープする必要があります。最初のパターンが最も好適であると仮定されるべきです。
This parameter describes a pattern or patterns for what keys are acceptable for signing for the digital signature enhancement. The pattern-info syntax for signing-key is:
このパラメータは、キーは、デジタル署名の強化のために署名するために許容可能であるもののためのパターンまたはパターンを記述する。署名キーのためのパターン情報の構文は次のとおりです。
pattern-info = name-domain "," pattern-data
パターン情報=名ドメイン「」パターンデータ
The only currently defined name-domain is 'DN-1779'. This parameter specifies desired values for fields of Distinguished Names. DNs are considered to be represented as specified in RFC1779, the order of fields and whitespace between fields is not significant.
唯一の現在定義されている名前、ドメイン「DN-1779」です。このパラメータは、識別名のフィールドに必要な値を指定します。 DNが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.
パターンデータは、フィールド値として許可正規表現を修正RFC1779の文字列です。パターンマッチは、フィールドごとに実行され、不特定のフィールドは、任意の値に一致する（従って任意のDNを可能DN-パターンは完全に不特定残します）。証明書チェーンは、（名前従属せずに証明書を許可する）だけでなく一致させることができます。発行者が指定する必要はないが、DN鎖は、そのすぐ右側に指定された証明書の発行人で左から右へ注文すると考えられています。末尾の「」 DNの配列が絶対であることを示しています。即ち右に1つの遠いがルートです。
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によって認証キーで署名1は、以下の式を使用することができることを要求します。コンマ（RFC1779フィールドセパレータ）とドット（正規表現メタキャラクタ）を保護するために引用POSIX 1003.2を保護するために引用RFC1779の使用に注意してください。
Your-Key-Pattern: signing-key, DN-1779, /OU=Persona Certificate, O="RSA Data Security, Inc\."/
あなたのキー・パターン：署名キー、DN-1779、/ OU =ペルソナ証明書、O = / "RSAデータセキュリティ社\。"
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-必要」など）指定されたモードとアクションのペアのためのデフォルトは暗黙的にマージされます。
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.
名前クラスは名前がMOSSの精神に、解釈されるべき内ドメインを表すASCII文字列です。 RFC1848のMOSS名形態に加えて、我々は、識別名のより便利な形を表現するためにDN-1779名の形式を追加します。
The argument is an RFC-1779 encoded DN.
引数は、DN符号化されたRFC-1779です。
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上の公開鍵の操作を可能にするために、送信者は、証明書情報オプションで認証情報を含むことができます。このオプションの形式は次のとおりです。
Certificate-Info: <Cert-Fmt>','<Cert-Group>
証明書情報：<証明書-FMT> '' <証明書-グループ>
<Cert-Fmt> should be the type of <Cert-Group> being presented.
<証明書-FMT>は提示されている<証明書-グループ>のタイプでなければなりません。
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」です。ベース64のSignerInfoフィールドの有無にかかわらず、証明書の配列を含むCMSのSignedDataメッセージを符号化されたようにCMS証明書グループが設けられています。 PEM形式の証明書グループは、コンマで区切られたbase64エンコードPEM証明書のリストです。
Multiple Certificate-Info lines may be defined.
複数の証明書情報ラインが定義されてもよいです。
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"
キー名=文字列の寿命=「この」| 「返信」| 「」メソッド=「インバンド」暗号=「ヌル」|暗号+暗号」= <セクションからヘッダー暗号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.
キー名は、このキーをバインドする先のシンボル名です。暗号（セクション3.2.4.7におけるヘッダ暗号のリストを参照）、このキーが潜在的に適用された暗号のリストです。キーワード「ヌル」は、任意の暗号で使用するためには不適切であることを示すために使用されなければなりません。これは、MACの計算のための鍵を交換するために有用である可能性があります。
Lifetime is a representation of the longest period of time during which the recipient of this message can expect the sender to accept that key. 'this' indicates that it is likely to be valid only for reading this transmission. 'reply' indicates that it is useful for a reply to this message. If a Key-Assign with the reply lifetime appears in a CRYPTOPTS block, it indicates that it is good for at least one (but perhaps only one) dereference of this anchor. An unspecified lifetime implies that this key may be reused for an indefinite number of transactions.
寿命は、このメッセージの受信者は送信者がそのキーを受け入れることを期待することができる時間の最長期間を表したものです。 「これは」それだけ、この伝送を読み取るための有効である可能性が高いことを示しています。 「返事は」それは、このメッセージへの返信のために有用であることを示しています。返信寿命とキーの割り当てはCRYPTOPTSブロックに表示された場合、それは、このアンカーの少なくとも一つの（おそらく唯一の）逆参照のために良いことを示しています。不特定寿命はこのキーがトランザクションの不特定多数のために再使用することができることを意味します。
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:
このヘッダによって定義されたキーは、構文を持つキーIDは、この明細書の他の箇所で言及されます。
Key-ID = method ":" key-name
キーID =法「：」キー名
This refers to the direct assignment of an uncovered key to a symbolic name. Method-args should be just the desired session key encoded in hexidecimal as in:
これはシンボリック名に覆われていないキーの直接割り当てを指します。この方法-argsがのように16進数でエンコードされただけで目的のセッションキーでなければなりません。
Key-Assign: inband,akey,reply,DES-ECB;0123456789abcdef
キーの割り当て：インバンド、AKEY、返信、DES-ECB; 0123456789ABCDEF
Short keys should be derived from long keys by reading bits from left to right.
ショートキーは左から右にビットを読み取ることによって、長いキーから導出されなければなりません。
Note that inband key assignment is especially important in order to permit confidential spontaneous communication between agents where one (but not both) of the agents have key pairs. However, this mechanism is also useful to permit key changes without public key computations. The key information is carried in this header line must be in the inner secured HTTP request, therefore use in unencrypted messages is not permitted.
キーの割り当て帯域内注剤の一つ（両方ではないが）鍵のペアを持っているエージェント間の機密自発的なコミュニケーションを可能にするために特に重要です。しかし、このメカニズムは、公開鍵計算せずにキーの変更を許可することも有用です。鍵情報は、したがって、内側保護された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.
ノンスは、鮮度のデモンストレーションを提供するために使用することができる不透明な、一過、セッション指向の識別子です。彼らはよく発信元によって生成されただけで、ランダムな数字かもしれないですが、Nonceの値は、ローカルの問題です。値は単純に供給され、受信者によって返されます。
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.
ノンスはノンスエコーヘッダ行に返されるべきです。セクション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の場合は、これらの文献は、NAMEタグを使用して命名されます）。名前は、カンマ区切りリストとしてスコープ属性に設けられ、セミコロンによって次のヘッダラインから分離されています。 SHTTP-Cryptoptsラインの形式は次のとおりです。
SHTTP-Cryptopts = "SHTTP-Cryptopts" ":" scope ";" cryptopt-list scope = "scope="<tag-spec> ; This is all one token without whitespace tag-spec = tag *("," tag) | "" cryptopt-list = cryptopt *(";" cryptopt) cryptopt = <S-HTTP cryptopt lines described below> tag = <value used in HTML anchor NAME attribute>
SHTTP-Cryptopts = "SHTTP-Cryptopts" "：" スコープ ";" cryptoptリストスコープ=「スコープ=」<タグスペック>;これは空白のタグスペック=タグ*（「」タグ）なしですべて1つのトークンです| "" cryptoptリスト= cryptopt×（ ";" cryptopt）cryptopt = <S-HTTP cryptopt線以下に説明>タグ= <HTMLアンカーNAME属性に使用される値>
For example:
例えば：
SHTTP-Cryptopts: scope=tag1,tag2; SHTTP-Privacy-Domains: orig-required=cms; recv-optional=cms,MOSS
SHTTP-Cryptopts：範囲= TAG1、TAG2。 SHTTP - プライバシー - ドメイン：ORIG-必要= CMS。 RECV-オプション= 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）にグループ化されたSHTTPネゴシエーションヘッダおよびヘッダの両方が含まれている場合、他のヘッダはSHTTP-Cryptopts線（複数可）に結合していないすべてのアンカーに適用すると解釈されなければなりません。これは全か無かの命題であることに注意してください。 SHTTP-Cryptoptsヘッダはオプションヘッダの一部がバインドオプションに表示されない場合でも、これらのグローバルオプションのいずれにも該当しない、その後、参照にオプションを結合する場合それは、です。むしろ、セクション3.2.4.11で見つかったS-HTTPのデフォルトが適用されます。
Two non-negotiation header lines for HTTP are defined here.
HTTPのための二つの非交渉ヘッダ行はここで定義されています。
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」、HTTP形式の認証と決済スキームの失敗を表す「402 PaymentRequired」。 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ヘッダのヘッダー。この応答は、次の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.
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.
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.
私たちも、通常の場合には、自動（ユーザの確認なし）の署名を阻止するので、上述した危険性を考えると、自動的に署名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忘れエージェントは、未知のプロトコル指定子を持つ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文書をサポートしてきましたが、以前のバージョンでは、実際にそれらを実装する方法を明らかにされていませんでした。基礎となるデータをHTTPリクエスト/レスポンスをpreenhancingとpreenhancing：このセクションでは、そうするために2つの方法について説明します。
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.
preenhanced文書のための2つの主な動機は、セキュリティとパフォーマンスです。これらの利点は、主に署名を生ずるだけでなく、特別な状況下での認証（MACベース）機密性又はrepudiableに適用することができます。
Consider the case of a server which repeatedly serves the same content to multiple clients. One such example would be a server which serves catalogs or price lists. Clearly, customers would like to be able to verify that these are actual prices. However, since the prices are typically the same to all comers, confidentiality is not an issue. (Note: see Section 7.1.5 below for how to deal with this case as well).
繰り返し複数のクライアントに同じコンテンツを提供していますサーバーの場合を考えてみましょう。その一例は、カタログや価格表を提供していますサーバーになります。明らかに、顧客は、これらが実際の価格であることを確認できるようにしたいと思います。価格は一般的に、すべてのニューカマーに同じであるためしかし、機密性は問題ではありません。 （注：この場合もに対処する方法については、以下のセクション7.1.5を参照してください）。
Consequently, the server might wish to sign the document once and simply send the cached signed document out when a client makes a new request, avoiding the overhead of a private key operation each time. Note that conceivably, the signed document might have been generated by a third party and placed in the server's cache. The server might not even have the signing key! This illustrates the security benefit of presigning: Untrusted servers can serve authenticated data without risk even if the server is compromised.
その結果、サーバはプライベートキー操作のオーバーヘッド各時間を避けて、一度文書に署名し、クライアントが新しい要求を行う際に、単純にキャッシュされた署名された文書を送信したい場合があります。おそらく、署名された文書は、第三者によって生成され、サーバーのキャッシュに配置されている可能性があることに注意してください。サーバーにも署名鍵を持っていない可能性があります！これはpresigningのセキュリティ上の利点を示しています。信頼されないサーバーでは、サーバーが危険にさらされてもリスクなしで認証されたデータを提供することができます。
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 messsageとして、それを送信するためにS-HTTPを使用しても可能です。これを実行するためには、（例えばS-HTTPリクエスト/レスポンスライン、コンテンツプライバシードメイン）と、必要なHTTPヘッダを（署名された文書（CMSまたはMOSSメッセージ）を取るとの両方がS-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ヘッダーを保護するためにそれ自体をカプセル化する必要があります。機密性が必要なときに明白な場合、[ここに示す1]はあるが、認証の強化、あるいはヌル変換の代わりに適用される可能性があります。すなわち、上記に示したメッセージは、のようなので、新しいS-HTTPメッセージ内のコンテンツとして使用することができるされています。
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.
NONCEがリクエストに含まれている場合、まだ文書データの否認防止を提供しながら、（ないドキュメント自体が）、このアプローチは、サーバ活性の新鮮さを提供するためにも使用できることに留意されたいです。
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が署名に最適ですが、それはまた、一定の条件の下で暗号化を使用することができます。同じ機密文書が繰り返して送信される状況を考えてみましょう。暗号化するのに費やした時間は、暗号文をキャッシュし、単に受信者ごとに新しい鍵交換ブロックを生成することにより保存することができます。 【MOSSと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意識プロキシは、要求（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応答コードを受信すると、プロキシが送信された暗号化オプションを読み取り、それをメッセージにその強調を適用する意思があるか否かを判断すべきです。クライアントがこれらの要件を満たすために喜んであれば、それは再帰的にそれが以前に適切なオプションを使用して送信された要求をカプセル化する必要があります。 （エンハンスメントを再帰的に適用されているので、明らかにサーバに要求を送信するために不本意であっても、クライアントはさらに、暗号化せずにプロキシにすでに暗号化されたメッセージを送信することをいとわないことに注意してください。）（再帰の別の例については、セクション7.1を参照してください。カプセル化されたメッセージ）
When the proxy receives such a message, it should strip the outer encapsulation to recover the message which should be sent to the server.
プロキシは、このようなメッセージを受信すると、サーバーに送信されるべきメッセージを回復するために、外側のカプセル化を除去すべきです。
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エージェントは、アウトバンド、インバンド、および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>
コンテンツプライバシードメイン：（ 'CMS' | 'MOSS'）予定・キー・インフォ：<HDR-暗号>、<キー>、<キーID>のContent-Type： 'というメッセージ/ HTTP' MAC-INFO：[ヘックス（TIMEOFDAY） ' '] <ハッシュ-ALG>'、 '六角（<ハッシュデータ>）'、' <キー仕様>
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>
キーの割り当て：<方法> ' '<キー名>'、 '<寿命>'、' <暗号> ';' <メソッド引数>暗号化・アイデンティティ：<名前クラス> '' <キー - SEL> ' '<名前-引数>証明書情報：<証明書-FMT>'、' <証明書-グループ>ナンス：<文字列>ナンス・エコー：<文字列>
SHTTP-Cryptopts: <scope>';'<string>(,<string>)* SHTTP-Privacy-Domains: ('CMS' | 'MOSS') SHTTP-Certificate-Types: ('X.509') SHTTP-Key-Exchange-Algorithms: ('DH', 'RSA' | 'Inband' | 'Outband') SHTTP-Signature-Algorithms: ('RSA' | 'NIST-DSS') SHTTP-Message-Digest-Algorithms: ('RSA-MD2' | 'RSA-MD5' | 'NIST-SHS' 'RSA-MD2-HMAC', 'RSA-MD5-HMAC', 'NIST-SHS-HMAC') SHTTP-Symmetric-Content-Algorithms: ('DES-CBC' | 'DES-EDE-CBC' | 'DES-EDE3-CBC' | 'DESX-CBC' | 'CDMF-CBC' | 'IDEA-CBC' | 'RC2-CBC' ) SHTTP-Symmetric-Header-Algorithms: ('DES-ECB' | 'DES-EDE-ECB' | 'DES-EDE3-EBC' | 'DESX-ECB' | 'CDMF-ECB' | 'IDEA-ECB' | 'RC2-ECB') SHTTP-Privacy-Enhancements: ('sign' | 'encrypt' | 'auth') Your-Key-Pattern: <key-use>','<pattern-info>
SHTTP-Cryptopts：<スコープ> ';' <文字列>（<文字列>）* SHTTP - プライバシー - ドメイン：（ 'CMS' | 'MOSS'）SHTTP - 証明書の種類：（ 'X.509'）SHTTP-鍵交換 - アルゴリズム：（ 'DH'、 'RSA' | 'インバンド' | '帯域外'）SHTTP - 署名 - アルゴリズム：（ 'RSA' | 'NIST-DSS'）SHTTP - メッセージダイジェスト・アルゴリズム：（」 RSA-MD2' | 'RSA-MD5' | 'NIST-SHS' 'RSA-MD2-HMAC'、 'RSA-MD5-HMAC'、 'NIST-SHS-HMAC'）SHTTP対称-コンテンツアルゴリズム：（」 DES-CBC」| 'DES-EDE-CBC' | 'DES-EDE3-CBC' | 'DESX-CBC' | 'CDMF-CBC' | 'IDEA-CBC' | 'RC2-CBC'）SHTTP対称-ヘッダー-Algorithms：（ 'DES-ECB' | 'DES-EDE-ECB' | 'DES-EDE3-EBC' | 'DESX-ECB' | 'CDMF-ECB' | 'IDEA-ECB' | 'RC2-ECB'） SHTTP - プライバシー - 強化：（「記号」|「暗号化」|「認証」）あなたのキー・パターン：<キーの使用>「」<パターン情報>
Secure * Secure-HTTP/1.4
セキュア*セキュア-HTTP / 1.4
Secure-HTTP/1.4 200 OK SecurityRetry 420 BogusHeader 421 <reason>
セキュア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:
アリスは、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
暗号化・アイデンティティ：DN-1779、ヌル、CN = SETEC天文学、OU =ペルソナ証明書、O = "RSA Data Security社"、C = US; SHTTP - プライバシー - 機能強化：RECV-必要=暗号化
<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.
区切り文字の間でのデータは、RSAがSETEC天文学のために包まCMSメッセージ、です。
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（インバンド：1,697fa820df8a6e53）
where 'inband:1' is the key exchanged in the Key-Assign line in the original request.
どこインバンド：1 'は、元の要求にキーの割り当てラインに交換した鍵です。
There is a link on the HTML page that was just returned, which Alice dereferences, creating the HTTP message:
アリスは、HTTPメッセージを作成、参照解除だけで返されたHTMLページ、上のリンクがあります：
============================================================
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の抽象構文記法（ASN.1、X.208で定義されている）で定義されており、具体的には（X. 209で定義されたBER）ASN.1の基本符号化規則を用いて表現されます。 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)
メッセージ= *コンテンツのコンテンツ=データ| SignedData | EnvelopedDataの| DigestedData | EncryptedDataデータ=バイトのSignedData = * DigestAlg内容*証明書*のCRLのSignerInfo * EnvelopedDataの= *のRecipientInfo BulkCryptAlg暗号化（コンテンツ）
DigestedData = DigestAlg Content DigestBytes EncryptedData = BulkCryptAlg Encrypted(Bytes) SignerInfo = CertID ... Encrypted(DigestBytes) ... RecipientInfo = CertID KeyCryptAlg Encrypted(DEK)
DigestedData = DigestAlgコンテンツDigestBytesはEncryptedData = BulkCryptAlg暗号化（バイト）のSignerInfo = CertID ...暗号化（DigestBytes）...のRecipientInfo = CertID KeyCryptAlg暗号化（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
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.
バージョン：同封のメッセージ（例えば「1.4」）のS-HTTPのバージョン番号。存在しない場合、バージョンは、本体の最初の行から決定することができます。
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]ベラー、M.、カネッティ、R.、Krawczyk、H.、 "メッセージ認証のためのキーイングハッシュ関数"、プレプリント。
[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日（1977年1月15日、FIPS PUBの46に取って代わる）を再確認しました。
[FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
[FIPS-81]連邦情報処理規格出版（FIPS PUBの）81、オペレーションのDESモード、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、1995年4月17日 "ハッシュ標準セキュア"。
[FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 1994 May 19.
[FIPS-186]連邦情報処理規格出版（FIPS PUBの）186、デジタル署名標準、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.
"公開鍵ネットワークにおける低指数精度とRSAの使用について、" [HAST86] Hastad、J.は、暗号理論-CRYPTO 95回の議事録、シュプリンガー・フェアラーク、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]ジョンソン、DB、マーチャーシュ、SM、ル、AV、ウィルキンス、JD、「商用データ・マスキング施設データプライバシーアルゴリズムの設計、」コンピュータ＆コミュニケーションセキュリティ上の議事録第一ACM会議、1993年11月、バージニア州フェアファクス、頁93から96。
[KRAW96b] Krawczyk, H. personal communication.
【KRAW96b] Krawczyk、H.パーソナルコミュニケーション。
[LAI92] Lai, X. "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
[LAI92]ライ、X. "ブロック暗号のデザインとセキュリティ上、" 情報処理におけるETHシリーズ、V 1、コンスタンツ：。アルトゥング-Gorre Verlag社、1992。
[PKCS-6] RSA Data Security, Inc. "Extended Certificate Syntax Standard", PKCS-6, Nov 1, 1993.
[PKCS-6] RSA Data Security社は1993年11月1日、PKCS-6 "証明書の構文標準を拡張"。
[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]クロッカー、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.、 "MD2メッセージダイジェストアルゴリズム"、RFC 1319、1992年4月。
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC-1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、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]リン、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]ケント、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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1993年9月。
[RFC-1738] T. Berners-Lee, "Uniform Resource Locators (URLs)", RFC 1738, December 1994.
[RFC-1738] T.バーナーズ=リー、 "ユニフォームリソースロケータ（URL）"、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]ガルビン、J.、マーフィー、S.、クロッカー、S.、およびN.フリード、 "MIMEのためのセキュリティMuliparts：マルチパート/署名およびマルチパート/暗号化"、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]クロッカー、S.、フリード、N.、ガルビン、J.、およびS.マーフィー、 "MIMEオブジェクトセキュリティサービス"、RFC 1848、1995年10月。
[RFC-1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[RFC-1864]マイヤーズ、J.とM.ローズ、 "コンテンツ-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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、「ハイパーテキスト転送プロトコル - HTTP / 1.1 「RFC 2616、1999年6月。
[RFC-2617] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC-2617]フランク、J.、ハラム・ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証"、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.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[SHTML] Rescorla, E. and A. Schiffman, "Security Extensions For HTML", RFC 2659, August 1999.
[SHTML]レスコラ、E.およびA.シフマン、 "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. Prennel及びP.バンOorschotは、「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
エリックレスコラRTFM、Inc.の30ニューウェル・ロード、＃16イーストパロアルト、CA 94303
Phone: (650) 328-8631 EMail: ekr@rtfm.com
電話：（650）328-8631 Eメール：ekr@rtfm.com
Allan M. Schiffman SPYRUS/Terisa 5303 Betsy Ross Drive Santa Clara, CA 95054
アランM.シフマンSPYRUS / Terisa 5303ベッツィー・ロスドライブサンタクララ、CA 95054
Phone: (408) 327-1901 EMail: ams@terisa.com
電話：（408）327-1901 Eメール：ams@terisa.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。