RFC5273 日本語訳
5273 Certificate Management over CMS (CMC): Transport Protocols. J.Schaad, M. Myers. June 2008. (Format: TXT=14030 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Schaad
Request for Comments: 5273 Soaring Hawk Consulting
Category: Standards Track M. Myers
TraceRoute Security, Inc.
June 2008
Schaadがコメントのために要求するワーキンググループJ.をネットワークでつないでください: カテゴリに相談する5273年の高く昇っているタカ: 標準化過程M.マイアーズトレースルートセキュリティInc.2008年6月
Certificate Management over CMS (CMC): Transport Protocols
cm(CMC)の上の管理を証明してください: トランスポート・プロトコル
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP.
このドキュメントはCMC(CMS(暗号のMessage Syntax)の上の証明書Management)メッセージを動かすのに使用される多くの移送機構を定義します。 本書では説明された移送機構は、HTTPと、ファイルと、メールと、TCPです。
1. Overview
1. 概要
This document defines a number of transport methods that are used to move CMC messages (defined in [CMC-STRUCT]). The transport mechanisms described in this document are HTTP, file, mail, and TCP.
このドキュメントはCMCメッセージ([CMC-STRUCT]では、定義される)を動かすのに使用される多くの輸送メソッドを定義します。 本書では説明された移送機構は、HTTPと、ファイルと、メールと、TCPです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUST].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[MUST]で説明されるように本書では解釈されることであるべきですか?
2. File-Based Protocol
2. ファイルベースのプロトコル
Enrollment messages and responses may be transferred between clients and servers using file-system-based mechanisms, such as when enrollment is performed for an off-line client. When files are used to transport binary, Full PKI Request or Full PKI Response messages, there MUST be only one instance of a request or response message in a single file. The following file type extensions SHOULD be used:
ファイルシステムベースのメカニズムを使用することで登録メッセージと応答をクライアントとサーバの間に移すかもしれません、登録がオフラインクライアントのために実行される時のように。 ファイルがバイナリー、Full PKI RequestまたはFull PKI Responseメッセージを輸送するのに使用されるとき、一列には要求か応答メッセージの1つのインスタンスしかないに違いありません。 以下のファイルは拡大SHOULDをタイプします。使用されてください:
Schaad & Myers Standards Track [Page 1] RFC 5273 CMC: Transport Protocols June 2008
Schaadとマイアーズ規格はRFC5273CMCを追跡します[1ページ]: トランスポート・プロトコル2008年6月
+---------------------+----------------+
| Message Type | File Extension |
+---------------------+----------------+
| Simple PKI Request | .p10 |
| Full PKI Request | .crq |
| Simple PKI Response | .p7c |
| Full PKI Response | .crp |
+---------------------+----------------+
+---------------------+----------------+ | メッセージタイプ| ファイル拡張子| +---------------------+----------------+ | 簡単なPKI要求| .p10| | 完全なPKI要求| .crq| | 簡単なPKI応答| .p7c| | 完全なPKI応答| .crp| +---------------------+----------------+
File PKI Request/Response Identification
ファイルPKI要求/応答識別
3. Mail-Based Protocol
3. メールベースのプロトコル
MIME wrapping is defined for those environments that are MIME native. The basic mime wrapping in this section is taken from [SMIMEV3]. When using a mail-based protocol, MIME wrapping between the layers of CMS wrapping is optional. Note that this is different from the standard S/MIME (Secure MIME) message.
MIMEラッピングはMIMEネイティブであるそれらの環境のために定義されます。 [SMIMEV3]からこのセクションの基本的なパントマイムラッピングを取ります。 メールベースのプロトコルを使用するとき、CMSラッピングの層の間のMIMEラッピングは任意です。 これが標準のS/MIME(安全なMIME)メッセージと異なっていることに注意してください。
Simple enrollment requests are encoded using the "application/pkcs10" content type. A file name MUST be included either in a content-type or a content-disposition statement. The extension for the file MUST be ".p10".
簡単な登録要求は、「アプリケーション/pkcs10"content type」を使用することでコード化されます。 content typeか満足している使途計算書にファイル名を含まなければなりません。 ファイルのための拡大は".p10""であるに違いありません。
Simple enrollment response messages MUST be encoded as content type "application/pkcs7-mime". An smime-type parameter MUST be on the content-type statement with a value of "certs-only". A file name with the ".p7c" extension MUST be specified as part of the content- type or content-disposition statement.
content type「pkcs7アプリケーション/パントマイム」として簡単な登録応答メッセージをコード化しなければなりません。 smime-型引数が「本命専用」の値と共にcontent type声明にあるに違いありません。 内容タイプか満足している使途計算書の一部として".p7c"拡大を伴うファイル名を指定しなければなりません。
Full enrollment request messages MUST be encoded as content type "application/pkcs7-mime". The smime-type parameter MUST be included with a value of "CMC-Request". A file name with the ".p7m" extension MUST be specified as part of the content-type or content-disposition statement.
content type「pkcs7アプリケーション/パントマイム」として完全な登録要求メッセージをコード化しなければなりません。 「CMC-要求」の値でsmime-型引数を含まなければなりません。 content typeか満足している使途計算書の一部として".p7m"拡大を伴うファイル名を指定しなければなりません。
Full enrollment response messages MUST be encoded as content type "application/pkcs7-mime". The smime-type parameter MUST be included with a value of "CMC-response". A file name with the ".p7m" extension MUST be specified as part of the content-type or content- disposition statement.
content type「pkcs7アプリケーション/パントマイム」として完全な登録応答メッセージをコード化しなければなりません。 「CMC-応答」の値でsmime-型引数を含まなければなりません。 content typeか内容使途計算書の一部として".p7m"拡大を伴うファイル名を指定しなければなりません。
Schaad & Myers Standards Track [Page 2] RFC 5273 CMC: Transport Protocols June 2008
Schaadとマイアーズ規格はRFC5273CMCを追跡します[2ページ]: トランスポート・プロトコル2008年6月
+--------------+------------------------+------------+--------------+ | Item | MIME Type | File | SMIME Type | | | | Extension | | +--------------+------------------------+------------+--------------+ | Simple PKI | application/pkcs10 | .p10 | N/A | | Request | | | | | Full PKI | application/pkcs7-mime | .p7m | CMC-request | | Request | | | | | Simple PKI | application/pkcs7-mime | .p7c | certs-only | | Response | | | | | Full PKI | application/pkcs7-mime | .p7m | CMC-response | | Response | | | | +--------------+------------------------+------------+--------------+
+--------------+------------------------+------------+--------------+ | 項目| MIMEの種類| ファイル| SMIMEはタイプします。| | | | 拡大| | +--------------+------------------------+------------+--------------+ | 簡単なPKI| アプリケーション/pkcs10| .p10| なし| | 要求| | | | | 完全なPKI| pkcs7アプリケーション/パントマイム| .p7m| CMC-要求| | 要求| | | | | 簡単なPKI| pkcs7アプリケーション/パントマイム| .p7c| 本命専用| | 応答| | | | | 完全なPKI| pkcs7アプリケーション/パントマイム| .p7m| CMC-応答| | 応答| | | | +--------------+------------------------+------------+--------------+
Table 1: MIME PKI Request/Response Identification
テーブル1: MIME PKI要求/応答識別
4. HTTP/HTTPS-Based Protocol
4. HTTPS HTTP/ベースのプロトコル
This section describes the conventions for use of HTTP [HTTP] as a transport layer. In most circumstances, the use of HTTP over TLS [TLS] provides any necessary content protection from eavesdroppers.
このセクションは、HTTP[HTTP]の使用のためにコンベンションをトランスポート層と説明します。 ほとんどの事情に、TLS[TLS]の上のHTTPの使用はどんな必要な満足している保護も立ち聞きする者から提供します。
In order for CMC clients and servers using HTTP to interoperate, the following rules apply.
CMCクライアントの注文と共同利用するのにHTTPを使用するサーバでは、以下の規則は適用されます。
Clients MUST use the POST method to submit their requests.
クライアントは彼らの要求を提出するポストメソッドを使用しなければなりません。
Servers MUST use the 200 response code for successful responses.
サーバはうまくいっている応答に200応答コードを使用しなければなりません。
Clients MAY attempt to send HTTP requests using TLS 1.0 [TLS] or
later, although servers are not required to support TLS.
クライアントは、TLS1.0以降[TLS]を使用することでHTTP要求を送るのを試みるかもしれません、サーバはTLSをサポートするのに必要ではありませんが。
Servers MUST NOT assume client support for any type of HTTP
authentication such as cookies, Basic authentication, or Digest
authentication.
サーバはHTTP認証のクッキー、Basic認証、またはDigest認証などのどんなタイプのクライアントサポートも仮定してはいけません。
Clients and servers are expected to follow the other rules and
restrictions in [HTTP]. Note that some of those rules are for
HTTP methods other than POST; clearly, only the rules that apply
to POST are relevant for this specification.
クライアントとサーバが[HTTP]における他の規則と制限に従うと予想されます。 それらの規則のいくつかがポスト以外のHTTPメソッドのためのものであることに注意してください。 この仕様において、ポストに適用される規則だけが関連しています。
4.1. PKI Request
4.1. PKI要求
A PKI Request using the POST method is constructed as follows:
ポストメソッドを使用するPKI Requestは以下の通り組み立てられます:
The Content-Type header MUST have the appropriate value from Table 1.
コンテントタイプヘッダーには、Table1からの適切な値がなければなりません。
Schaad & Myers Standards Track [Page 3] RFC 5273 CMC: Transport Protocols June 2008
Schaadとマイアーズ規格はRFC5273CMCを追跡します[3ページ]: トランスポート・プロトコル2008年6月
The body of the message is the binary value of the encoding of the PKI Request.
メッセージ欄はPKI Requestのコード化の2進の値です。
4.2. PKI Response
4.2. PKI応答
An HTTP-based PKI Response is composed of the appropriate HTTP headers, followed by the binary value of the BER (Basic Encoding Rules) encoding of either a Simple or Full PKI Response.
HTTPベースのPKI ResponseはSimpleかFull PKI ResponseのどちらかのBER(基本的なEncoding Rules)コード化の2進の値があとに続いた適切なHTTPヘッダで構成されます。
The Content-Type header MUST have the appropriate value from Table 1.
コンテントタイプヘッダーには、Table1からの適切な値がなければなりません。
5. TCP-Based Protocol
5. TCPベースのプロトコル
When CMC messages are sent over a TCP-based connection, no wrapping is required of the message. Messages are sent in their binary encoded form.
TCPベースの接続の上にCMCメッセージを送るとき、包装でないのにメッセージを要求します。 それらの2進のコード化されたフォームでメッセージを送ります。
The client closes a connection after receiving a response, or it issues another request to the server using the same connection. Reusing one connection for multiple successive requests, instead of opening multiple connections that are only used for a single request, is RECOMMENDED for performance and resource conservation reasons. A server MAY close a connection after it has been idle for some period of time; this timeout would typically be several minutes long.
応答を受けた後に、クライアントが接続を終えるか、またはそれは、同じ接続を使用することで別の要求をサーバに出します。 性能と資源保護理由でただ一つの要求がRECOMMENDEDであるので、使用されるだけである複数の接続を開くことの代わりに複数の連続した要求のために1つの接続を再利用します。 いつかの期間の間、活動していなくなっている後にサーバは接続を終えるかもしれません。 このタイムアウトは通常長さ数分でしょう。
There is no specific port that is to be used when doing TCP-based transport. Only the Private Ports 49152-65535 may be used in this manner (without registration). The ports in the range of 1-49151 SHOULD NOT be used. The port to be used is configured out of band.
TCPベースの輸送をするとき使用されていることになっているどんな特定のポートもありません。 この様に(登録なしで)兵士のPorts49152-65535だけを使用してもよいです。 ポート、1-49151 SHOULD NOTの範囲では、使用されてください。 使用されるべきポートはバンドから構成されます。
6. Security Considerations
6. セキュリティ問題
Mechanisms for thwarting replay attacks may be required in particular implementations of this protocol depending on the operational environment. In cases where the Certification Authority (CA) maintains significant state information, replay attacks may be detectable without the inclusion of the optional nonce mechanisms. Implementers of this protocol need to carefully consider environmental conditions before choosing whether or not to implement the senderNonce and recipientNonce attributes described in Section 6.6 of [CMC-STRUCT]. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these attributes.
反射攻撃を阻むためのメカニズムが運用環境に依存するこのプロトコルの特定の実装で必要であるかもしれません。 認証局(カリフォルニア)が重要な州の情報を保守する場合では、反射攻撃は任意の一回だけのメカニズムの包含なしで検出可能であるかもしれません。このプロトコルのImplementersは、senderNonceとrecipientNonceが[CMC-STRUCT]のセクション6.6で説明された属性であると実装するかどうかを選ぶ前に慎重に環境条件を考える必要があります。 状態が強制的なPKIクライアントの開発者がこれらの属性の使用を取り入れるよう強く奨励されます。
Initiation of a secure communications channel between an end-entity and a CA or Registration Authority (RA) -- and, similarly, between an RA and another RA or CA -- necessarily requires an out-of-band trust initiation mechanism. For example, a secure channel may be constructed between the end-entity and the CA via IPsec [IPsec] or
a安全なコミュニケーションの開始は同様に終わり実体とカリフォルニアかRegistration Authority(RA)の間と、そして、別のRAとRAかカリフォルニアの間で精神を集中します--必ず、バンドで出ている信頼開始メカニズムを必要とします。 または例えば、安全なチャンネルがIPsec[IPsec]を通して終わり実体とカリフォルニアの間で構成されるかもしれない。
Schaad & Myers Standards Track [Page 4] RFC 5273 CMC: Transport Protocols June 2008
Schaadとマイアーズ規格はRFC5273CMCを追跡します[4ページ]: トランスポート・プロトコル2008年6月
TLS [TLS]. Many such schemes exist, and the choice of any particular scheme for trust initiation is outside the scope of this document. Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability within an overall security architecture.
TLS[TLS]。 そのような多くの体系が存在しています、そして、このドキュメントの範囲の外に信頼開始のどんな特定の体系の選択もあります。 総合的なセキュリティー体系の中でこの能力を統合するとき、このプロトコルのImplementersが安全なかぎ管理の一般に認められた原則を考えるよう強く奨励されます。
In some instances, no prior out-of-band trust will have been initiated prior to use of this protocol. This can occur when the protocol itself is being used to download onto the system the set of trust anchors to be used for these protocols. In these instances, the Enveloped Data content type (Section 3.2.1.3.3 in [CMC-STRUCT]) must be used to provide the same shrouding that TLS would have provided.
ある場合に、どんな先のバンドで出ている信頼もこのプロトコルの使用の前に開始されていないでしょう。 プロトコル自体がこれらのプロトコルに使用されるために信頼アンカーのセットをシステムにダウンロードするのに使用されているとき、これは起こることができます。 これらのインスタンス、Enveloped Data content type、(セクション3.2 .1 .3 TLSが提供したのと同じの覆い隠すことを提供するのに[CMC-STRUCT)の.3を使用しなければなりません。
7. Acknowledgments
7. 承認
The authors and the PKIX Working Group are grateful for the participation of Xiaoyi Liu and Jeff Weinstein in helping to author the original versions of this document.
このドキュメントのオリジナルバージョンを書くのを助ける際に作者とPKIX作業部会はXiaoyiリュウとジェフ・ワインスタインの参加に感謝しています。
The authors would like to thank Brian LaMacchia for his work in developing and writing up many of the concepts presented in this document. The authors would also like to thank Alex Deacon and Barb Fox for their contributions.
作者は彼の仕事について本書では提示された概念の多くを開発して、詳しく書く際にブライアンLaMacchiaに感謝したがっています。 また、作者は彼らの貢献についてアレックスDeaconとバーブフォックスに感謝したがっています。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[CMC-STRUCT] Schaad, J. and M. Myers, "Certificate Management over
CMS (CMC)", RFC 5272, June 2008.
[CMC-STRUCT] SchaadとJ.とM.マイアーズ、「cm(CMC)の上の証明書管理」、RFC5272、2008年6月。
[HTTP] 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.
[HTTP] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[IPsec] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[IPsec] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[MUST] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[MUST]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、1997年3月。
[SMIMEV3] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[SMIMEV3] Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
Schaad & Myers Standards Track [Page 5] RFC 5273 CMC: Transport Protocols June 2008
Schaadとマイアーズ規格はRFC5273CMCを追跡します[5ページ]: トランスポート・プロトコル2008年6月
8.2. Informative References
8.2. 有益な参照
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346,
April 2006.
[TLS] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
Authors' Addresses
作者のアドレス
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
ジムSchaad高く昇るタカのコンサルティング私書箱675金の延べ棒、ワシントン 98251
Phone: (425) 785-1031 EMail: jimsch@nwlink.com
以下に電話をしてください。 (425) 785-1031 メールしてください: jimsch@nwlink.com
Michael Myers TraceRoute Security, Inc.
マイケルマイアーズトレースルートセキュリティInc.
EMail: mmyers@fastq.com
メール: mmyers@fastq.com
Schaad & Myers Standards Track [Page 6] RFC 5273 CMC: Transport Protocols June 2008
Schaadとマイアーズ規格はRFC5273CMCを追跡します[6ページ]: トランスポート・プロトコル2008年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Schaad & Myers Standards Track [Page 7]
Schaadとマイアーズ標準化過程[7ページ]
一覧
スポンサーリンク
