RFC3851 日本語訳
3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1Message Specification. B. Ramsdell, Ed.. July 2004. (Format: TXT=53328 bytes) (Obsoletes RFC2633) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Ramsdell, Editor Request for Comments: 3851 Sendmail, Inc. Obsoletes: 2633 July 2004 Category: Standards Track
ワーキンググループB.Ramsdell、コメントを求めるエディタ要求をネットワークでつないでください: 3851 センドメールInc.は以下を時代遅れにします。 2633 2004年7月のカテゴリ: 標準化過程
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
Message Specification
安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633.
このドキュメントはSecure/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1を定義します。 S/MIMEは安全なMIMEデータを送って、受け取る一貫した方法を提供します。 デジタル署名は認証、メッセージの保全、および非拒否を発生源の証拠に提供します。 暗号化はデータの機密性を提供します。 データサイズを減少させるのに圧縮を使用できます。 このドキュメントはRFC2633を時代遅れにします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification Overview . . . . . . . . . . . . . . . . . 3
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Definitions. . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Compatibility with Prior Practice of S/MIME. . . . . . . 5
1.5. Changes Since S/MIME v3. . . . . . . . . . . . . . . . . 5
2. CMS Options. . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. DigestAlgorithmIdentifier. . . . . . . . . . . . . . . . 5
2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 6
2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 6
2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 6
2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 7
2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 11
2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 12
3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . . 14
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 仕様概要. . . . . . . . . . . . . . . . . 3 1.2。 用語。 . . . . . . . . . . . . . . . . . . . . . . 3 1.3. 定義。 . . . . . . . . . . . . . . . . . . . . . . 4 1.4. S/MIMEの先の習慣との互換性。 . . . . . . 5 1.5. Since S/MIME v3を変えます。 . . . . . . . . . . . . . . . . 5 2. cmはゆだねます。 . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. DigestAlgorithmIdentifier。 . . . . . . . . . . . . . . . 5 2.2. SignatureAlgorithmIdentifier. . . . . . . . . . . . . . 6 2.3。 KeyEncryptionAlgorithmIdentifier. . . . . . . . . . . . 6 2.4。 一般構文. . . . . . . . . . . . . . . . . . . . . 6 2.5。 属性とSignerInfoは.72.6をタイプします。 SignerIdentifier SignerInfoは.112.7をタイプします。 ContentEncryptionAlgorithmIdentifier. . . . . . . . . . 12 3。 S/MIMEメッセージ. . . . . . . . . . . . . . . . . . . 14を作成します。
Ramsdell Standards Track [Page 1] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[1ページ]RFCメッセージ仕様2004年7月
3.1. Preparing the MIME Entity for Signing, Enveloping
or Compressing . . . . . . . . . . . . . . . . . . . . . 14
3.2. The application/pkcs7-mime Type. . . . . . . . . . . . . 19
3.3. Creating an Enveloped-only Message . . . . . . . . . . . 21
3.4. Creating a Signed-only Message . . . . . . . . . . . . . 22
3.5. Creating an Compressed-only Message. . . . . . . . . . . 26
3.6. Multiple Operations. . . . . . . . . . . . . . . . . . . 27
3.7. Creating a Certificate Management Messagetoc . . . . . . 27
3.8. Registration Requests. . . . . . . . . . . . . . . . . . 28
3.9. Identifying an S/MIME Message. . . . . . . . . . . . . . 28
4. Certificate Processing . . . . . . . . . . . . . . . . . . . . 29
4.1. Key Pair Generation. . . . . . . . . . . . . . . . . . . 29
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
B. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
B.1. Normative References . . . . . . . . . . . . . . . . . . 32
B.2. Informative References . . . . . . . . . . . . . . . . . 34
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
D. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
3.1. 署名、おおうことまたは圧縮. . . . . . . . . . . . . . . . . . . . . 14 3.2のためのMIME実体を準備します。 pkcs7アプリケーション/パントマイムType。 . . . . . . . . . . . . 19 3.3. おおわれて唯一のメッセージ. . . . . . . . . . . 21 3.4を作成します。 署名されて唯一のメッセージ. . . . . . . . . . . . . 22 3.5を作成します。 作成、圧縮されて唯一のメッセージ。 . . . . . . . . . . 26 3.6. 同時併行処理。 . . . . . . . . . . . . . . . . . . 27 3.7. 証明書管理Messagetoc. . . . . . 27 3.8を作成します。 登録要求。 . . . . . . . . . . . . . . . . . 28 3.9. S/MIMEメッセージを特定します。 . . . . . . . . . . . . . 28 4. 処理. . . . . . . . . . . . . . . . . . . . 29 4.1を証明してください。 主要な組世代。 . . . . . . . . . . . . . . . . . . 29 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 29 A.ASN.1モジュール. . . . . . . . . . . . . . . . . . . . . . . . . 31B.参照. . . . . . . . . . . . . . . . . . . . . . . . . . 32B.1。 引用規格. . . . . . . . . . . . . . . . . . 32B.2。 有益な参照. . . . . . . . . . . . . . . . . 34C.承認. . . . . . . . . . . . . . . . . . . . . . . 35D.エディタのアドレスの.35の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 36
1. Introduction
1. 序論
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures), and data confidentiality (using encryption).
S/MIME(安全な/マルチパーパスインターネットメールエクステンション)は安全なMIMEデータを送って、受け取る一貫した方法を提供します。 ポピュラーなインターネットMIME規格に基づいて、S/MIMEは電子メッセージ通信アプリケーションのための以下の暗号のセキュリティー・サービスを提供します: 発生源(デジタル署名を使用する)、およびデータの機密性(暗号化を使用する)の認証、メッセージの保全、および非拒否。
S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems.
伝統的なメールユーザエージェント(MUAs)は、暗号のセキュリティー・サービスを送られるメールに追加して、受け取られていているメールで暗号のセキュリティー・サービスを解釈するのにS/MIMEを使用できます。 しかしながら、S/MIMEはメールに制限されません。 HTTPなどのMIMEデータを輸送するどんな移送機構と共にもそれを使用できます。 そういうものとして、S/MIMEは、MIMEのオブジェクトベースの特徴を利用して、複雑な輸送システムで交換されるべき安全なメッセージを許容します。
Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet.
さらに、少しの人間の介入も必要としない暗号のセキュリティー・サービスを使用する自動メッセージ証券代行でS/MIMEを使用できます、ソフトウェアで発生しているドキュメントの署名やインターネットの上に送られたFAXメッセージの暗号化のように。
Ramsdell Standards Track [Page 2] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[2ページ]RFCメッセージ仕様2004年7月
1.1. Specification Overview
1.1. 仕様概要
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. The MIME standard [MIME-SPEC] provides a general structure for the content type of Internet messages and allows extensions for new content type applications.
このドキュメントは、暗号の署名と暗号化サービスをMIMEデータに追加するためにプロトコルについて説明します。 MIME規格[MIME-SPEC]は、インターネットメッセージのcontent typeに一般構造体を提供して、新しいcontent typeアプリケーションのために拡大を許します。
This specification defines how to create a MIME body part that has been cryptographically enhanced according to CMS [CMS], which is derived from PKCS #7 [PKCS-7]. This specification also defines the application/pkcs7-mime MIME type that can be used to transport those body parts.
この仕様はPKCS#7[PKCS-7]から得られるCMS[CMS]に応じて暗号で高められたMIME身体の部分を作成する方法を定義します。 また、この仕様はそれらの身体の部分を輸送するのに使用できるpkcs7アプリケーション/パントマイムMIMEの種類を定義します。
This document also discusses how to use the multipart/signed MIME type defined in [MIME-SECURE] to transport S/MIME signed messages. multipart/signed is used in conjunction with the application/pkcs7- signature MIME type, which is used to transport a detached S/MIME signature.
また、このドキュメントは複合の、または、署名しているメッセージであると署名されるS/MIMEを輸送するために[MIME-SECURE]で定義された複合の、または、署名しているMIMEの種類を使用するのがどうアプリケーション/pkcs7署名MIMEの種類に関連して使用されているかについて議論します。MIMEの種類は離れているS/MIME署名を輸送するのにおいて使用されています。
In order to create S/MIME messages, an S/MIME agent MUST follow the specifications in this document, as well as the specifications listed in the Cryptographic Message Syntax document [CMS] [CMSALG].
S/MIMEメッセージを作成するために、S/MIMEエージェントは本書では仕様に従わなければなりません、Cryptographic Message Syntaxドキュメント[CMS][CMSALG]にリストアップされた仕様と同様に。
Throughout this specification, there are requirements and recommendations made for how receiving agents handle incoming messages. There are separate requirements and recommendations for how sending agents create outgoing messages. In general, the best strategy is to "be liberal in what you receive and conservative in what you send". Most of the requirements are placed on the handling of incoming messages while the recommendations are mostly on the creation of outgoing messages.
この仕様中に、要件がありました、そして、推薦は受信エージェントがどう入力メッセージを扱うかになりました。 送付エージェントがどう送信されるメッセージを作成するか別々の要件と推薦があります。 「一般に、最も良い戦略はあなたが受けるもので寛容であって、あなたが送るもので保守的である」ことです。 推薦がほとんど送信されるメッセージの作成にある間、要件の大部分は入力メッセージの取り扱いに置かれます。
The separation for requirements on receiving agents and sending agents also derives from the likelihood that there will be S/MIME systems that involve software other than traditional Internet mail clients. S/MIME can be used with any system that transports MIME data. An automated process that sends an encrypted message might not be able to receive an encrypted message at all, for example. Thus, the requirements and recommendations for the two types of agents are listed separately when appropriate.
また、エージェントを受けて、エージェントを送ることに関する要件のための分離はある見込みから伝統的なインターネット・メールクライアント以外のソフトウェアにかかわるS/MIMEシステムを引き出します。 MIMEデータを輸送するどんなシステムと共にもS/MIMEを使用できます。 暗号化メッセージを送る自動化されたプロセスは全く、そして、例えば暗号化メッセージを受け取ることができないかもしれません。 適切であるときに、したがって、2つのタイプのエージェントのための要件と推薦は別々にリストアップされます。
1.2. Terminology
1.2. 用語
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 [MUSTSHOULD].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[MUSTSHOULD]で説明されるように本書では解釈されることであるべきですか?
Ramsdell Standards Track [Page 3] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[3ページ]RFCメッセージ仕様2004年7月
1.3. Definitions
1.3. 定義
For the purposes of this specification, the following definitions apply.
この仕様の目的のために、以下の定義は申し込まれます。
ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208 [X.208-88].
ASN.1: CCITT X.208[X.208-88]で定義されるような抽象的なSyntax Notation One。
BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209 [X.209-88].
BER: ASN.1のためのCCITT X.209[X.209-88]で定義されるような基本的なEncoding Rules。
Certificate: A type that binds an entity's name to a public key with a digital signature.
以下を証明してください。 デジタル署名で実体の名前を公開鍵に縛るタイプ。
DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT X.509 [X.509-88].
DER: ASN.1のためのCCITT X.509[X.509-88]で定義されるような顕著なEncoding Rules。
7-bit data: Text data with lines less than 998 characters long, where none of the characters have the 8th bit set, and there are no NULL characters. <CR> and <LF> occur only as part of a <CR><LF> end of line delimiter.
7ビットのデータ: 系列998キャラクタが長いテキストデータ、キャラクタのだれにも8番目のビットがないところにセットしてください。そうすれば、NULLキャラクタが全くありません。 <CR>と<LF>は単に<CR><LF>行末デリミタの一部として現れます。
8-bit data: Text data with lines less than 998 characters, and where none of the characters are NULL characters. <CR> and <LF> occur only as part of a <CR><LF> end of line delimiter.
8ビットのデータ: 系列が998のキャラクタとキャラクタのだれもどこのNULLキャラクタでないかより少ないテキストデータ。 <CR>と<LF>は単に<CR><LF>行末デリミタの一部として現れます。
Binary data: Arbitrary data.
バイナリ・データ: 任意のデータ。
Transfer Encoding: A reversible transformation made on data so 8-bit or binary data can be sent via a channel that only transmits 7-bit data.
コード化を移してください: 7ビットのデータを送るだけであるチャンネルであまりに8ビットであるデータでされた可逆的な変換かバイナリ・データを送ることができます。
Receiving agent: Software that interprets and processes S/MIME CMS objects, MIME body parts that contain CMS content types, or both.
エージェントを受けます: S/MIME CMSオブジェクトを解釈して、処理するソフトウェア、CMS content typeを含むMIME身体の部分、または両方。
Sending agent: Software that creates S/MIME CMS content types, MIME body parts that contain CMS content types, or both.
エージェントを送ります: S/MIME CMS content typeを作成するソフトウェア、CMS content typeを含むMIME身体の部分、または両方。
S/MIME agent: User software that is a receiving agent, a sending agent, or both.
S/MIMEエージェント: 受信エージェント、送付エージェント、または両方であるユーザソフトウェア。
Ramsdell Standards Track [Page 4] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[4ページ]RFCメッセージ仕様2004年7月
1.4. Compatibility with Prior Practice of S/MIME
1.4. S/MIMEの先の習慣との互換性
S/MIME version 3.1 agents SHOULD attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive and S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive. RFC 2311 also has historical information about the development of S/MIME.
S/MIMEバージョン3.1エージェントSHOULDは、最もすばらしい相互運用性をエージェントでS/MIMEの先のバージョンに可能にするのを試みます。 S/MIMEバージョン2はRFC2315を通してRFC2311で説明されます、包括的であり、S/MIMEバージョン3はRFC2634を通してRFC2630で包括的に説明されます。 また、RFC2311には、S/MIMEの開発に関する歴史に関する知識があります。
1.5. Changes Since S/MIME v3
1.5. Since S/MIME v3を変えます。
The RSA public key algorithm was changed to a MUST implement key wrapping algorithm, and the Diffie-Hellman algorithm changed to a SHOULD implement.
RSA公開鍵アルゴリズムはaに変えて、道具がラッピングアルゴリズムを合わせなければならなくて、ディフィー-ヘルマンアルゴリズムがSHOULD道具に変化したということでした。
The AES symmetric encryption algorithm has been included as a SHOULD implement.
AESの左右対称の暗号化アルゴリズムはSHOULD道具として含まれています。
The RSA public key algorithm was changed to a MUST implement signature algorithm.
RSA公開鍵アルゴリズムは変えて、aが署名アルゴリズムを実装しなければならないということでした。
Ambiguous language about the use of "empty" SignedData messages to transmit certificates was clarified to reflect that transmission of certificate revocation lists is also allowed.
証明書を伝える「空」のSignedDataメッセージの使用に関するあいまいな言語は、また、証明書失効リストの送信が許されているのを反映するためにはっきりさせられました。
The use of binary encoding for some MIME entities is now explicitly discussed.
現在、明らかに2進のコード化のいくつかのMIME実体の使用について議論します。
Header protection through the use of the message/rfc822 MIME type has been added.
メッセージ/rfc822MIMEの種類の使用によるヘッダー保護は加えられます。
Use of the CompressedData CMS type is allowed, along with required MIME type and file extension additions.
CompressedData CMSタイプの使用は必要なMIMEの種類とファイル拡張子追加と共に許されています。
2. CMS Options
2. cmはゆだねます。
CMS allows for a wide variety of options in content and algorithm support. This section puts forth a number of support requirements and recommendations in order to achieve a base level of interoperability among all S/MIME implementations. [CMSALG] provides additional details regarding the use of the cryptographic algorithms.
CMSは内容とアルゴリズムサポートにおけるさまざまなオプションを考慮します。 このセクションは、すべてのS/MIME実装の中で基準面の相互運用性を達成するために多くのサポート要件と推薦を差し出します。 [CMSALG]は暗号アルゴリズムの使用に関する追加詳細を明らかにします。
2.1. DigestAlgorithmIdentifier
2.1. DigestAlgorithmIdentifier
Sending and receiving agents MUST support SHA-1 [CMSALG]. Receiving agents SHOULD support MD5 [CMSALG] for the purpose of providing backward compatibility with MD5-digested S/MIME v2 SignedData objects.
送受信エージェントはSHA-1[CMSALG]をサポートしなければなりません。 MD5によって読みこなされたS/MIME v2 SignedDataオブジェクトを後方の互換性に提供する目的のために、エージェントSHOULDサポートMD5[CMSALG]を受けます。
Ramsdell Standards Track [Page 5] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[5ページ]RFCメッセージ仕様2004年7月
2.2. SignatureAlgorithmIdentifier
2.2. SignatureAlgorithmIdentifier
Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. The algorithm parameters MUST be absent (not encoded as NULL). Receiving agents MUST support rsaEncryption, defined in [CMSALG].
エージェントを受けると、sha1とイドdsaは[CMSALG]で定義されていた状態でサポートしなければなりません。 アルゴリズムパラメタは欠けているに違いありません(NULLとして、コード化されません)。 エージェントを受けると、[CMSALG]で定義されたrsaEncryptionはサポートしなければなりません。
Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
送付エージェントはsha1とイドdsaかrsaEncryptionのどちらかをサポートしなければなりません。
If using rsaEncryption, sending and receiving agents MUST support the digest algorithms in section 2.1 as specified.
rsaEncryptionを使用するなら、送受信エージェントは、指定されるとしてセクション2.1でダイジェストがアルゴリズムであるとサポートしなければなりません。
Note that S/MIME v3 clients might only implement signing or signature verification using id-dsa-with-sha1, and might also use id-dsa as an AlgorithmIdentifier in this field. Receiving clients SHOULD recognize id-dsa as equivalent to id-dsa-with-sha1, and sending clients MUST use id-dsa-with-sha1 if using that algorithm. Also note that S/MIME v2 clients are only required to verify digital signatures using the rsaEncryption algorithm with SHA-1 or MD5, and might not implement id-dsa-with-sha1 or id-dsa at all.
S/MIME v3クライアントがsha1とイドdsaを使用することで署名か署名照合を実装するだけであり、また、AlgorithmIdentifierとしてこの分野でイド-dsaを使用するかもしれないことに注意してください。 受信クライアントSHOULDは同等な同じくらいイド-dsaをsha1とイドdsaに認識します、そして、そのアルゴリズムを使用するなら、送付クライアントはsha1とイドdsaを使用しなければなりません。 また、S/MIME v2クライアントがSHA-1かMD5があるrsaEncryptionアルゴリズムを使用することでデジタル署名について確かめるのが必要であるだけであり、sha1とイドdsaか全くイド-dsaを実装しないかもしれないことに注意してください。
2.3. KeyEncryptionAlgorithmIdentifier
2.3. KeyEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support rsaEncryption, defined in [CMSALG].
送受信エージェントは[CMSALG]で定義されたrsaEncryptionをサポートしなければなりません。
Sending and receiving agents SHOULD support Diffie-Hellman defined in [CMSALG], using the ephemeral-static mode.
はかなく静的なモードを使用して、ディフィー-ヘルマンが[CMSALG]で定義したエージェントSHOULDサポートを送って、受けます。
Note that S/MIME v3 clients might only implement key encryption and decryption using the Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only capable of decrypting content-encryption keys using the rsaEncryption algorithm.
S/MIME v3クライアントが、主要な暗号化と復号化使用がディフィー-ヘルマンアルゴリズムであると実装するだけであるかもしれないことに注意してください。 また、S/MIME v2クライアントがrsaEncryptionアルゴリズムを使用することで満足している暗号化キーを解読することができるだけであることに注意してください。
2.4. General Syntax
2.4. 一般構文
There are several CMS content types. Of these, only the Data, SignedData, EnvelopedData, and CompressedData content types are currently used for S/MIME.
いくつかのCMS content typeがあります。 これらでは、Data、SignedData、EnvelopedData、およびCompressedData content typeだけが現在、S/MIMEに使用されます。
2.4.1. Data Content Type
2.4.1. データcontent type
Sending agents MUST use the id-data content type identifier to identify the "inner" MIME message content. For example, when applying a digital signature to MIME data, the CMS SignedData encapContentInfo eContentType MUST include the id-data object identifier and the MIME content MUST be stored in the SignedData encapContentInfo eContent OCTET STRING (unless the sending agent is using multipart/signed, in which case the eContent is absent, per
送付エージェントは、「内側」のMIMEメッセージ内容を特定するのにイドデータcontent type識別子を使用しなければなりません。 MIMEデータにデジタル署名を適用するとき、例えば、CMS SignedData encapContentInfo eContentTypeはイドデータ・オブジェクト識別子を含まなければなりません、そして、SignedData encapContentInfo eContent OCTET STRINGにMIME内容を保存しなければなりません。(送付エージェントが複合か署名された状態で使用していない場合、その場合、eContentは欠けています。
Ramsdell Standards Track [Page 6] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[6ページ]RFCメッセージ仕様2004年7月
section 3.4.3 of this document). As another example, when applying encryption to MIME data, the CMS EnvelopedData encryptedContentInfo contentType MUST include the id-data object identifier and the encrypted MIME content MUST be stored in the EnvelopedData encryptedContentInfo encryptedContent OCTET STRING.
この.3通のセクション3.4ドキュメント) MIMEデータに暗号化を適用するとき、別の例として、CMS EnvelopedData encryptedContentInfo contentTypeはイドデータ・オブジェクト識別子を含まなければなりません、そして、EnvelopedData encryptedContentInfo encryptedContent OCTET STRINGに暗号化されたMIME内容を保存しなければなりません。
2.4.2. SignedData Content Type
2.4.2. SignedData content type
Sending agents MUST use the SignedData content type to apply a digital signature to a message or, in a degenerate case where there is no signature information, to convey certificates. Applying a signature to a message provides authentication, message integrity, and non-repudiation of origin.
送付エージェントがデジタル署名をメッセージに適用するのにSignedData content typeを使用しなければならない、堕落した場合では、さもなければ、そこのどこが、証明書を伝えるためには署名情報でないか。 署名をメッセージに適用すると、発生源の認証、メッセージの保全、および非拒否は提供されます。
2.4.3. EnvelopedData Content Type
2.4.3. EnvelopedData content type
This content type is used to apply data confidentiality to a message. A sender needs to have access to a public key for each intended message recipient to use this service.
このcontent typeは、データの機密性をメッセージに適用するのに使用されます。 送付者は、それぞれの意図しているメッセージ受取人がこのサービスを利用するように公開鍵に近づく手段を持つ必要があります。
2.4.4. CompressedData Content Type
2.4.4. CompressedData content type
This content type is used to apply data compression to a message. This content type does not provide authentication, message integrity, non-repudiation, or data confidentiality, and is only used to reduce message size.
このcontent typeは、データ圧縮をメッセージに適用するのに使用されます。 このcontent typeは、認証、メッセージの保全、非拒否、またはデータの機密性を提供しないで、メッセージサイズを減少させるのに使用されるだけです。
See section 3.6 for further guidance on the use of this type in conjunction with other CMS types.
他のCMSに関連したこのタイプの使用のさらなる指導のためのセクション3.6がタイプされるのを確実にしてください。
2.5. Attributes and the SignerInfo Type
2.5. 属性とSignerInfoはタイプします。
The SignerInfo type allows the inclusion of unsigned and signed attributes to be included along with a signature.
SignerInfoタイプは署名と共に未署名の、そして、署名している属性の包含を含めさせます。
Receiving agents MUST be able to handle zero or one instance of each of the signed attributes listed here. Sending agents SHOULD generate one instance of each of the following signed attributes in each S/MIME message:
エージェントを受けると、ここに記載されたそれぞれの署名している属性のゼロか1つのインスタンスを扱うことができなければなりません。 送付エージェントSHOULDはそれぞれのS/MIMEメッセージの属性であると署名されるそれぞれの以下の1つのインスタンスを生成します:
- signingTime (section 2.5.1 in this document) - sMIMECapabilities (section 2.5.2 in this document) - sMIMEEncryptionKeyPreference (section 2.5.3 in this document) - id-messageDigest (section 11.2 in [CMS]) - id-contentType (section 11.1 in [CMS])
- signingTime(このドキュメントのセクション2.5.1)--sMIMECapabilities(このドキュメントのセクション2.5.2)--sMIMEEncryptionKeyPreference(このドキュメントのセクション2.5.3)--イド-messageDigest([CMS]のセクション11.2)--イド-contentType([cm]のセクション11.1)
Ramsdell Standards Track [Page 7] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[7ページ]RFCメッセージ仕様2004年7月
Further, receiving agents SHOULD be able to handle zero or one instance in the signingCertificate signed attribute, as defined in section 5 of [ESS].
エージェントSHOULDを受けて、さらに、属性であると署名されるsigningCertificateのゼロか1つのインスタンスを扱うことができてください、[ESS]のセクション5で定義されるように。
Sending agents SHOULD generate one instance of the signingCertificate signed attribute in each SignerInfo structure.
送付エージェントSHOULDはそれぞれのSignerInfo構造で属性であると署名されるsigningCertificateの1つのインスタンスを生成します。
Additional attributes and values for these attributes might be defined in the future. Receiving agents SHOULD handle attributes or values that it does not recognize in a graceful manner.
これらの属性のための追加属性と値は将来、定義されるかもしれません。 受信エージェントSHOULDはそれが優しい物腰で認識しない属性か値を扱います。
Interactive sending agents that include signed attributes that are not listed here SHOULD display those attributes to the user, so that the user is aware of all of the data being signed.
ここに記載されていなくて、SHOULDはそれらの属性をユーザに表示します、ユーザが署名されるデータのすべてを意識しているようにことである署名している属性を含んでいる対話的な送付エージェント。
2.5.1. Signing-Time Attribute
2.5.1. 署名時間属性
The signing-time attribute is used to convey the time that a message was signed. The time of signing will most likely be created by a message originator and therefore is only as trustworthy as the originator.
署名時間属性は、メッセージが署名された時間を伝えるのに使用されます。 署名の時間は、たぶんメッセージ創始者によって作成されて、したがって、単に創始者と同じくらい信頼できます。
Sending agents MUST encode signing time through the year 2049 as UTCTime; signing times in 2050 or later MUST be encoded as GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST interpret the year field (YY) as follows:
送付エージェントはUTCTimeとして署名時間から2049年をコード化しなければなりません。 GeneralizedTimeとして2050か後で回に署名するのをコード化しなければなりません。 UTCTime CHOICEが使用されているとき、S/MIMEエージェントは以下の1年の分野(YY)を解釈しなければなりません:
if YY is greater than or equal to 50, the year is interpreted as 19YY; if YY is less than 50, the year is interpreted as 20YY.
YYが50歳以上であるなら、1年は19YYとして解釈されます。 YYが50歳未満であるなら、1年は20YYとして解釈されます。
2.5.2. SMIMECapabilities Attribute
2.5.2. SMIMECapabilities属性
The SMIMECapabilities attribute includes signature algorithms (such as "sha1WithRSAEncryption"), symmetric algorithms (such as "DES- EDE3-CBC"), and key encipherment algorithms (such as "rsaEncryption"). There are also several identifiers which indicate support for other optional features such as binary encoding and compression. The SMIMECapabilities were designed to be flexible and extensible so that, in the future, a means of identifying other capabilities and preferences such as certificates can be added in a way that will not cause current clients to break.
SMIMECapabilities属性は署名アルゴリズム("sha1WithRSAEncryption"などの)、左右対称のアルゴリズム(「デスEDE3-CBC」などの)、および主要な暗号文アルゴリズム("rsaEncryption"などの)を含んでいます。 また、2進のコード化や圧縮などの他のオプション機能のサポートを示すいくつかの識別子があります。 将来現在のクライアントが中断していない方法で証明書などの他の能力と好みを特定する手段を加えることができて、SMIMECapabilitiesは、フレキシブルであって、広げることができるように設計されました。
If present, the SMIMECapabilities attribute MUST be a SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the SMIMECapabilities attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A
存在しているなら、SMIMECapabilities属性はSignedAttributeであるに違いありません。 それはUnsignedAttributeであるはずがありません。 CMSはSignedAttributesをSET OF Attributeと定義します。 signerInfoのSignedAttributesはSMIMECapabilities属性の複数のインスタンスを含んではいけません。 AttributeがattrValues SET OF AttributeValueを含むように、CMSはASN.1構文を定義します。 A
Ramsdell Standards Track [Page 8] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[8ページ]RFCメッセージ仕様2004年7月
SMIMECapabilities attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
SMIMECapabilities属性はAttributeValueのただ一つのインスタンスを含むだけでよいです。 attrValues SET OF AttributeValueの現在のAttributeValueのゼロか複数のインスタンスがあるはずがありません。
The semantics of the SMIMECapabilities attribute specify a partial list as to what the client announcing the SMIMECapabilities can support. A client does not have to list every capability it supports, and need not list all its capabilities so that the capabilities list doesn't get too long. In an SMIMECapabilities attribute, the object identifiers (OIDs) are listed in order of their preference, but SHOULD be separated logically along the lines of their categories (signature algorithms, symmetric algorithms, key encipherment algorithms, etc.)
SMIMECapabilitiesを発表するクライアントが何にサポートすることができるかとSMIMECapabilities属性の意味論は部分的なリストを指定します。 クライアントがそれがサポートするあらゆる能力を記載する必要はなくて、すべての能力を記載しなければならないというわけではないので、能力リストは長くなり過ぎません。 しかし、彼らの好み、SHOULDの順にSMIMECapabilities属性では、オブジェクト識別子(OIDs)がリストアップされている、それらのカテゴリの系列に沿って論理的に切り離されてください。(署名アルゴリズム、左右対称のアルゴリズム、主要な暗号文アルゴリズムなど)
The structure of the SMIMECapabilities attribute is to facilitate simple table lookups and binary comparisons in order to determine matches. For instance, the DER-encoding for the SMIMECapability for DES EDE3 CBC MUST be identically encoded regardless of the implementation. Because of the requirement for identical encoding, individuals documenting algorithms to be used in the SMIMECapabilities attribute SHOULD explicitly document the correct byte sequence for the common cases.
SMIMECapabilities属性の構造はマッチを決定するために簡単な索表と2進の比較を容易にすることです。 例えば、実装にかかわらずコード化されて、DES EDE3 CBC MUSTのためのSMIMECapabilityのためのDER-コード化は同様にそうです。 同じコード化のための要件のために、SMIMECapabilities属性SHOULDで明らかに使用されるためにアルゴリズムを記録する個人はよくある例のために正しいバイト列を記録します。
For any capability, the associated parameters for the OID MUST specify all of the parameters necessary to differentiate between two instances of the same algorithm. For instance, the number of rounds and the block size for RC5 needs to be specified in addition to the key length.
どんな能力としても、OID MUSTのための関連パラメタは同じアルゴリズムの2つのインスタンスを区別するのに必要なパラメタのすべてを指定します。 例えば、ラウンドの数とRC5のためのブロック・サイズは、キー長に加えて指定される必要があります。
The OIDs that correspond to algorithms SHOULD use the same OID as the actual algorithm, except in the case where the algorithm usage is ambiguous from the OID. For instance, in an earlier specification, rsaEncryption was ambiguous because it could refer to either a signature algorithm or a key encipherment algorithm. In the event that an OID is ambiguous, it needs to be arbitrated by the maintainer of the registered SMIMECapabilities list as to which type of algorithm will use the OID, and a new OID MUST be allocated under the smimeCapabilities OID to satisfy the other use of the OID.
アルゴリズムSHOULDに対応するOIDsは実際のアルゴリズムと同じOIDを使用します、ケースを除いて中アルゴリズム用法がOIDからあいまいである。 例えば、以前の仕様では、署名アルゴリズムか主要な暗号文アルゴリズムのどちらかを示すかもしれないので、rsaEncryptionはあいまいでした。 OIDがあいまいである場合、それは、OIDのもう片方の使用を満たすためにsmimeCapabilities OIDの下にどのタイプのアルゴリズムがOID、および新しいOID MUSTを使用するために望んでいるかに割り当てるように登録されたSMIMECapabilitiesリストの維持装置によって仲裁される必要があります。
The registered SMIMECapabilities list specifies the parameters for OIDs that need them, most notably key lengths in the case of variable-length symmetric ciphers. In the event that there are no differentiating parameters for a particular OID, the parameters MUST be omitted, and MUST NOT be encoded as NULL.
登録されたSMIMECapabilitiesリストは彼ら(著しく可変長の左右対称の暗号の場合におけるほとんどのキー長)を必要とするOIDsのためのパラメタを指定します。 差別化パラメタが全く特定のOIDのためにない場合、パラメタは、省略しなければならなくて、NULLとしてコード化されてはいけません。
Ramsdell Standards Track [Page 9] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[9ページ]RFCメッセージ仕様2004年7月
Additional values for the SMIMECapabilities attribute might be defined in the future. Receiving agents MUST handle a SMIMECapabilities object that has values that it does not recognize in a graceful manner.
SMIMECapabilities属性のための加算値は将来、定義されるかもしれません。 エージェントを受けると、それが優しい物腰で認識しない値を持っているSMIMECapabilitiesオブジェクトは扱われなければなりません。
Section 2.7.1 explains a strategy for caching capabilities.
セクション2.7 .1 能力をキャッシュするための戦略を説明します。
2.5.2.1. SMIMECapability For the RC2 Algorithm
2.5.2.1. RC2アルゴリズムのためのSMIMECapability
For the RC2 algorithm preference SMIMECapability, the capabilityID MUST be set to the value rc2-cbc as defined in [CMSALG]. The parameters field MUST contain SMIMECapabilitiesParametersForRC2CBC (see appendix A).
RC2アルゴリズム好みのSMIMECapabilityにおいて、capabilityIDは[CMSALG]で定義される値のrc2-cbcに用意ができなければなりません。 パラメタ分野はSMIMECapabilitiesParametersForRC2CBCを含まなければなりません(付録Aを見てください)。
Please note that the SMIMECapabilitiesParametersForRC2CBC is a single INTEGER which contains the effective key length (NOT the corresponding RC2 parameter version value). So, for example, for RC2 with a 128-bit effective key length, the parameter would be encoded as the INTEGER value 128, NOT the corresponding parameter version of 58.
SMIMECapabilitiesParametersForRC2CBCはINTEGERです有効なキー長(対応するRC2パラメタバージョン価値でない)を含む独身の。 それで、例えば128ビットの有効なキー長があるRC2に関して、INTEGERが対応するパラメタバージョンではなく、58の128を評価するとき、パラメタはコード化されるでしょう。
2.5.3. Encryption Key Preference Attribute
2.5.3. 暗号化の主要な好みの属性
The encryption key preference attribute allows the signer to unambiguously describe which of the signer's certificates has the signer's preferred encryption key. This attribute is designed to enhance behavior for interoperating with those clients that use separate keys for encryption and signing. This attribute is used to convey to anyone viewing the attribute which of the listed certificates is appropriate for encrypting a session key for future encrypted messages.
署名者の証明書について署名者の都合のよい暗号化キーを持っている署名者が主要な好みの属性で明白に説明できる暗号化。 この属性は、暗号化に別々のキーを使用するそれらのクライアントと共に共同利用するための振舞いを機能アップするように設計されていて、署名しています。 この属性は将来の暗号化メッセージに、主要なセッションを暗号化するために記載された証明書で適切な属性を見るのにおいてだれまでも運ぶのにおいて使用されています。
If present, the SMIMEEncryptionKeyPreference attribute MUST be a SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A SMIMEEncryptionKeyPreference attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
存在しているなら、SMIMEEncryptionKeyPreference属性はSignedAttributeであるに違いありません。 それはUnsignedAttributeであるはずがありません。 CMSはSignedAttributesをSET OF Attributeと定義します。 signerInfoのSignedAttributesはSMIMEEncryptionKeyPreference属性の複数のインスタンスを含んではいけません。 AttributeがattrValues SET OF AttributeValueを含むように、CMSはASN.1構文を定義します。 SMIMEEncryptionKeyPreference属性はAttributeValueのただ一つのインスタンスを含むだけでよいです。 attrValues SET OF AttributeValueの現在のAttributeValueのゼロか複数のインスタンスがあるはずがありません。
The sending agent SHOULD include the referenced certificate in the set of certificates included in the signed message if this attribute is used. The certificate MAY be omitted if it has been previously made available to the receiving agent. Sending agents SHOULD use this attribute if the commonly used or preferred encryption
送付エージェントSHOULDは、この属性が使用されているなら署名しているメッセージに証明書のセットにおける参照をつけられた証明書を含んでいるのを含んでいます。 以前にそれを受信エージェントにとって利用可能にしたなら、証明書を省略するかもしれません。 一般的に使用されたか都合のよい暗号化であるならエージェントSHOULD使用にこの属性を送ります。
Ramsdell Standards Track [Page 10] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[10ページ]RFCメッセージ仕様2004年7月
certificate is not the same as the certificate used to sign the message.
証明書は証明書が以前はよくメッセージに署名していたのと同じではありません。
Receiving agents SHOULD store the preference data if the signature on the message is valid and the signing time is greater than the currently stored value. (As with the SMIMECapabilities, the clock skew SHOULD be checked and the data not used if the skew is too great.) Receiving agents SHOULD respect the sender's encryption key preference attribute if possible. This, however, represents only a preference and the receiving agent can use any certificate in replying to the sender that is valid.
メッセージにおける署名が有効であり、署名時間が現在保存された値より大きいなら、受信エージェントSHOULDは好みのデータを保存します。 SMIMECapabilitiesのように、チェックされて、時計はSHOULDを歪曲します。(斜行であるなら使用されないデータがすばらし過ぎる、) できれば、受信エージェントSHOULDは送付者の暗号化の主要な好みの属性を尊敬します。 しかしながら、これは優先だけを表します、そして、受信エージェントは有効な送付者に答える際にどんな証明書も使用できます。
Section 2.7.1 explains a strategy for caching preference data.
セクション2.7 .1 好みのデータをキャッシュするための戦略を説明します。
2.5.3.1. Selection of Recipient Key Management Certificate
2.5.3.1. 受取人Key Management証明書の選択
In order to determine the key management certificate to be used when sending a future CMS EnvelopedData message for a particular recipient, the following steps SHOULD be followed:
以下は、特定の受取人のために将来のCMS EnvelopedDataメッセージを送るとき、かぎ管理証明書が使用されることを決定するためにSHOULDを踏みます。続かれてください:
- If an SMIMEEncryptionKeyPreference attribute is found in a
SignedData object received from the desired recipient, this
identifies the X.509 certificate that SHOULD be used as the X.509
key management certificate for the recipient.
- SMIMEEncryptionKeyPreference属性が必要な受取人から受け取られたSignedDataオブジェクトで見つけられるなら、これは受取人へのX.509かぎ管理証明書として使用されていた状態でSHOULDがあるX.509証明書を特定します。
- If an SMIMEEncryptionKeyPreference attribute is not found in a
SignedData object received from the desired recipient, the set of
X.509 certificates SHOULD be searched for a X.509 certificate with
the same subject name as the signing of a X.509 certificate which
can be used for key management.
- SMIMEEncryptionKeyPreference属性がそうなら、必要な受取人、X.509証明書SHOULDのセットから受け取られていているSignedDataオブジェクトで見つけられないで、X.509の署名がどれを証明するかときかぎ管理に同じ対象の名前があるX.509証明書を使用できるので、捜されてください。
- Or use some other method of determining the user's key management
key. If a X.509 key management certificate is not found, then
encryption cannot be done with the signer of the message. If
multiple X.509 key management certificates are found, the S/MIME
agent can make an arbitrary choice between them.
- または、ユーザのかぎ管理キーを決定するある他のメソッドを使用してください。 X.509かぎ管理証明書を見つけないなら、メッセージの署名者で暗号化ができません。 複数のX.509かぎ管理証明書が見つけられるなら、S/MIMEエージェントはそれらの気紛れな選択をすることができます。
2.6. SignerIdentifier SignerInfo Type
2.6. SignerIdentifier SignerInfoはタイプします。
S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as well as subjectKeyIdentifier. Messages that use the subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
S/MIME v3.1実装はissuerAndSerialNumberとsubjectKeyIdentifierの両方をサポートしなければなりません。 S/MIME v2クライアントはsubjectKeyIdentifier選択を使用するメッセージを読むことができません。
It is important to understand that some certificates use a value for subjectKeyIdentifier that is not suitable for uniquely identifying a certificate. Implementations MUST be prepared for multiple certificates for potentially different entities to have the same value for subjectKeyIdentifier, and MUST be prepared to try each
いくつかの証明書が唯一証明書を特定するのに適当でないsubjectKeyIdentifierに値を使用するのを理解しているのは重要です。 実装は、それぞれを試みるために潜在的に異なった実体のための複数の証明書にはsubjectKeyIdentifierのための同じ値があるように準備していなければならなくて、準備していなければなりません。
Ramsdell Standards Track [Page 11] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[11ページ]RFCメッセージ仕様2004年7月
matching certificate during signature verification before indicating an error condition.
エラー条件を示す前に、署名照合の間、証明書を合わせます。
2.7. ContentEncryptionAlgorithmIdentifier
2.7. ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Receiving agents SHOULD support encryption and decryption using the RC2 [CMSALG] or a compatible algorithm at a key size of 40 bits, hereinafter called "RC2/40". Sending and receiving agents SHOULD support encryption and decryption with AES [CMSAES] at a key size of 128, 192, and 256 bits.
「tripleDES」[CMSALG]は、以下に、送受信エージェントがDES EDE3 CBCと共に暗号化と復号化をサポートしなければならないと呼びました。 受信エージェントSHOULDは、40ビットと、以下に呼ばれた「RC2/40インチ」の主要なサイズで暗号化と復号化使用がRC2[CMSALG]かコンパチブルアルゴリズムであるとサポートします。 送受信エージェントSHOULDはAES[CMSAES]と共に128、192、および256ビットの主要なサイズで暗号化と復号化をサポートします。
2.7.1. Deciding Which Encryption Method To Use
2.7.1. どの暗号化メソッドを使用したらよいかを決めます。
When a sending agent creates an encrypted message, it has to decide which type of encryption to use. The decision process involves using information garnered from the capabilities lists included in messages received from the recipient, as well as out-of-band information such as private agreements, user preferences, legal restrictions, and so on.
送付エージェントが暗号化メッセージを作成するとき、それは、どのタイプの暗号化を使用するかを決めなければなりません。 プロセスが、能力リストから集められる情報を使用することを伴うという決定は受取人から受け取られたメッセージと、バンドの外に個人的な協定、ユーザー選択、法的規制などなどの情報を含んでいました。
Section 2.5.2 defines a method by which a sending agent can optionally announce, among other things, its decrypting capabilities in its order of preference. The following method for processing and remembering the encryption capabilities attribute in incoming signed messages SHOULD be used.
セクション2.5 .2 よく使われる順で送付エージェントが能力を特に解読すると任意に発表できるメソッドを定義します。 メッセージSHOULDであると署名される入来における暗号化能力属性が使用されたのを処理して、覚えているための以下のメソッド。
- If the receiving agent has not yet created a list of capabilities
for the sender's public key, then, after verifying the signature
on the incoming message and checking the timestamp, the receiving
agent SHOULD create a new list containing at least the signing
time and the symmetric capabilities.
- 受信エージェントが送付者の公開鍵のためにまだ能力のリストを作成していないなら、入力メッセージで署名について確かめて、タイムスタンプをチェックした後に、受信エージェントSHOULDは少なくとも署名時間と左右対称の能力を含む新しいリストを作成します。
- If such a list already exists, the receiving agent SHOULD verify
that the signing time in the incoming message is greater than the
signing time stored in the list and that the signature is valid.
If so, the receiving agent SHOULD update both the signing time and
capabilities in the list. Values of the signing time that lie far
in the future (that is, a greater discrepancy than any reasonable
clock skew), or a capabilities list in messages whose signature
could not be verified, MUST NOT be accepted.
- そのようなリストが既に存在しているなら、受信エージェントSHOULDは入力メッセージの署名時間がリストに保存された署名時間より長く、署名が有効であることを確かめます。 そうだとすれば、受信エージェントSHOULDは署名時間とリストの能力の両方をアップデートします。 遠くに未来(すなわち、どんな合理的な時計斜行よりも重大な食い違い)に、ある署名現代の値、またはメッセージの署名について確かめることができなかった能力リストを受け入れてはいけません。
The list of capabilities SHOULD be stored for future use in creating messages.
能力SHOULDについて記載してください。メッセージを作成することにおける未来の使用には、保存されてください。
Before sending a message, the sending agent MUST decide whether it is willing to use weak encryption for the particular data in the
メッセージを送る前に、送付エージェントは、それが、特定のデータに中で弱い暗号化を使用しても構わないと思っているかどうか決めなければなりません。
Ramsdell Standards Track [Page 12] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[12ページ]RFCメッセージ仕様2004年7月
message. If the sending agent decides that weak encryption is unacceptable for this data, then the sending agent MUST NOT use a weak algorithm such as RC2/40. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use.
メッセージ。 送付エージェントが、このデータに、弱い暗号化が容認できないと決めるなら、送付エージェントはRC2/40などの弱いアルゴリズムを使用してはいけません。 弱い暗号化が使用するためにどの暗号化アルゴリズムに関してこのセクションでのいかなる他の決定もくつがえす使用ではなく、使用する決定。
Sections 2.7.2.1 through 2.7.2.4 describe the decisions a sending agent SHOULD use in deciding which type of encryption will be applied to a message. These rules are ordered, so the sending agent SHOULD make its decision in the order given.
セクション2.7 .2 .1〜2.7に、.4が暗号化のどのタイプについて決めるかながら送付エージェントSHOULDが使用する決定について説明する.2はメッセージに適用されるでしょう。 これらの規則が注文されるので、送付エージェントSHOULDはオーダーにおける決定を与えさせます。
2.7.1.1. Rule 1: Known Capabilities
2.7.1.1. 規則1: 知られている能力
If the sending agent has received a set of capabilities from the recipient for the message the agent is about to encrypt, then the sending agent SHOULD use that information by selecting the first capability in the list (that is, the capability most preferred by the intended recipient) that the sending agent knows how to encrypt. The sending agent SHOULD use one of the capabilities in the list if the agent reasonably expects the recipient to be able to decrypt the message.
送付エージェントがエージェントが暗号化しようとしているメッセージのために受取人から1セットの能力を受けたなら、送付エージェントSHOULDは、送付エージェントが、どのようにが暗号化するかを知っているリスト(すなわち、意図している受取人によって最も好まれた能力)における最初の能力を選択することによって、その情報を使用します。 エージェントが、受取人がメッセージを解読することができると合理的に予想するなら、送付エージェントSHOULDはリストで能力の1つを使用します。
2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME
2.7.1.2. 規則2: 未知の能力、S/MIMEの未知のバージョン
If the following two conditions are met:
- the sending agent has no knowledge of the encryption capabilities
of the recipient,
- and the sending agent has no knowledge of the version of S/MIME of
the recipient,
then the sending agent SHOULD use tripleDES because it is a stronger
algorithm and is required by S/MIME v3. If the sending agent chooses
not to use tripleDES in this step, it SHOULD use RC2/40.
以下の2つの条件が満たされるなら: - 送付エージェントには、受取人の暗号化能力に関する知識が全くなくて、送付エージェントでは、受取人のS/MIMEのバージョンに関する知識が全くなくて、それが、より強いアルゴリズムであり、S/MIME v3によって必要とされるので、次に、送付エージェントSHOULDはtripleDESを使用します。 送付エージェントが、中でtripleDESを使用しないのを選ぶなら、これは踏まれて、それはSHOULD使用です。RC2/40。
2.7.2. Choosing Weak Encryption
2.7.2. 弱い暗号化を選びます。
Like all algorithms that use 40 bit keys, RC2/40 is considered by many to be weak encryption. A sending agent that is controlled by a human SHOULD allow a human sender to determine the risks of sending data using RC2/40 or a similarly weak encryption algorithm before sending the data, and possibly allow the human to use a stronger encryption method such as tripleDES.
40ビットのキーを使用するすべてのアルゴリズムのように、RC2/40は多くによって弱い暗号化であると考えられます。 SHOULDがデータを送る前にRC2/40を使用することでデータを送る危険か同様に弱い暗号化アルゴリズムを決定して、ことによると人間がtripleDESなどの、より強い暗号化メソッドを使用するのを許容するのを人間の送付者を許容する人間によって監督される送付エージェント。
2.7.3. Multiple Recipients
2.7.3. 複数の受取人
If a sending agent is composing an encrypted message to a group of recipients where the encryption capabilities of some of the recipients do not overlap, the sending agent is forced to send more than one message. Please note that if the sending agent chooses to
送付エージェントが何人かの受取人の暗号化能力が重ならない受取人のグループに暗号化メッセージを構成しているなら、送付エージェントはやむを得ず1つ以上のメッセージを送ります。 送付エージェントが、選ぶなら、それに注意してください。
Ramsdell Standards Track [Page 13] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[13ページ]RFCメッセージ仕様2004年7月
send a message encrypted with a strong algorithm, and then send the same message encrypted with a weak algorithm, someone watching the communications channel could learn the contents of the strongly- encrypted message simply by decrypting the weakly-encrypted message.
強いアルゴリズムで暗号化されたメッセージを送って、弱いアルゴリズムで暗号化された同じメッセージがその時発信し、コミュニケーションチャンネルを監視しているだれかが、単に弱々しく暗号化されたメッセージを解読することによって、強く暗号化されたメッセージのコンテンツを学ぶことができるでしょう。
3. Creating S/MIME Messages
3. S/MIMEメッセージを作成します。
This section describes the S/MIME message formats and how they are created. S/MIME messages are a combination of MIME bodies and CMS content types. Several MIME types as well as several CMS content types are used. The data to be secured is always a canonical MIME entity. The MIME entity and other data, such as certificates and algorithm identifiers, are given to CMS processing facilities which produce a CMS object. Finally, the CMS object is wrapped in MIME. The Enhanced Security Services for S/MIME [ESS] document provides descriptions of how nested, secured S/MIME messages are formatted. ESS provides a description of how a triple-wrapped S/MIME message is formatted using multipart/signed and application/pkcs7-mime for the signatures.
このセクションはS/MIMEメッセージ・フォーマットとそれらがどう作成されるかを説明します。 S/MIMEメッセージはMIME本体とCMS content typeの組み合わせです。 いくつかのCMS content typeと同様にいくつかのMIMEの種類が使用されています。 いつも保証されるデータは正準なMIME実体です。 証明書やアルゴリズム識別子などのMIME実体と他のデータをCMSオブジェクトを作り出すCMS処理施設に与えます。 最終的に、CMSオブジェクトはMIMEで包装されます。 [ESS]が記録するS/MIMEのためのEnhanced Security Servicesは入れ子にされて、機密保護しているS/MIMEメッセージがどうフォーマットされるかに関する記述を提供します。 ESSは3倍包装されたS/MIMEメッセージが署名に署名される複合/とpkcs7アプリケーション/パントマイムを使用することでどうフォーマットされるかに関する記述を提供します。
S/MIME provides one format for enveloped-only data, several formats for signed-only data, and several formats for signed and enveloped data. Several formats are required to accommodate several environments, in particular for signed messages. The criteria for choosing among these formats are also described.
S/MIMEはおおわれて唯一のデータのための1つの形式、署名されて唯一のデータのためのいくつかの形式、および署名していておおわれたデータのためのいくつかの形式を提供します。 いくつかの形式が、いくつかの環境を収容するのに特に署名しているメッセージに必要です。 また、これらの形式の中で選ぶ評価基準は説明されます。
The reader of this section is expected to understand MIME as described in [MIME-SPEC] and [MIME-SECURE].
このセクションの読者が[MIME-SPEC]と[MIME-SECURE]で説明されるようにMIMEを理解していると予想されます。
3.1. Preparing the MIME Entity for Signing, Enveloping or Compressing
3.1. 署名のためにMIME実体を準備するか、おおうことまたは圧縮
S/MIME is used to secure MIME entities. A MIME entity can be a sub- part, sub-parts of a message, or the whole message with all its sub- parts. A MIME entity that is the whole message includes only the MIME headers and MIME body, and does not include the RFC-822 headers. Note that S/MIME can also be used to secure MIME entities used in applications other than Internet mail. If protection of the RFC-822 headers is required, the use of the message/rfc822 MIME type is explained later in this section.
S/MIMEは、MIMEが実体であると機密保護するのに使用されます。 MIME実体は、サブ部分、メッセージのサブ部分、またはすべてのサブの部品がある全体のメッセージであるかもしれません。 全体のメッセージであるMIME実体は、MIMEヘッダーとMIME本体だけを含んでいて、RFC-822ヘッダーは含んでいません。 また、MIMEがインターネット・メール以外のアプリケーションで使用される実体であると機密保護するのにS/MIMEを使用できることに注意してください。 RFC-822ヘッダーの保護が必要であるなら、メッセージ/rfc822MIMEの種類の使用は後でこのセクションで説明されます。
The MIME entity that is secured and described in this section can be thought of as the "inside" MIME entity. That is, it is the "innermost" object in what is possibly a larger MIME message. Processing "outside" MIME entities into CMS content types is described in Section 3.2, 3.4, and elsewhere.
“inside"MIME実体としてこのセクションで保証されて、説明されるMIME実体は考えることができます。 すなわち、それはことによるとより大きいMIMEメッセージであることで「最も奥深い」オブジェクトです。 CMS content typeへのMIME実体を処理するのはセクション3.2、3.4と、ほかの場所に「外に」に説明されます。
The procedure for preparing a MIME entity is given in [MIME-SPEC]. The same procedure is used here with some additional restrictions
MIME実体が[MIME-SPEC]で与えられている準備のための手順。 同じ手順はいくつかの追加制限と共にここで用いられます。
Ramsdell Standards Track [Page 14] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[14ページ]RFCメッセージ仕様2004年7月
when signing. Description of the procedures from [MIME-SPEC] are repeated here, but it is suggested that the reader refer to that document for the exact procedure. This section also describes additional requirements.
署名するとき。 [MIME-SPEC]からの手順の記述はここで繰り返されますが、読者が正確な手順のためのそのドキュメントを参照することが提案されます。 また、このセクションは追加要件について説明します。
A single procedure is used for creating MIME entities that are to have any combination of signing, enveloping, and compressing applied. Some additional steps are recommended to defend against known corruptions that can occur during mail transport that are of particular importance for clear-signing using the multipart/signed format. It is recommended that these additional steps be performed on enveloped messages, or signed and enveloped messages, so that the message can be forwarded to any environment without modification.
ただ一つの手順は署名のどんな組み合わせも持つことになっているMIME実体を作成するのに用いられます、おおって、圧縮は適用されました。 追加数ステップが明確な署名のために特別に重要なメール輸送の間に複合の、または、署名している形式を使用することで起こることができる知られている贈収賄に対して防御することが勧められます。 これらの追加ステップがおおわれたメッセージ、または署名していておおわれたメッセージに実行されるのは、お勧めです、変更なしでどんな環境にもメッセージを転送できるように。
These steps are descriptive rather than prescriptive. The implementer is free to use any procedure as long as the result is the same.
規範的であるというよりむしろこれらのステップは描写的です。 結果が同じである限り、implementerは自由にどんな手順も用いることができます。
Step 1. The MIME entity is prepared according to the local conventions.
1を踏んでください。 地方のコンベンションによると、MIME実体は準備されます。
Step 2. The leaf parts of the MIME entity are converted to canonical form.
2を踏んでください。 MIME実体の葉の部品は標準形に変換されます。
Step 3. Appropriate transfer encoding is applied to the leaves of the MIME entity.
3を踏んでください。 適切な転送コード化はMIME実体の葉に当てられます。
When an S/MIME message is received, the security services on the message are processed, and the result is the MIME entity. That MIME entity is typically passed to a MIME-capable user agent where, it is further decoded and presented to the user or receiving application.
S/MIMEメッセージが受信されているとき、メッセージにおけるセキュリティー・サービスは処理されます、そして、結果はMIME実体です。 MIME有能なユーザエージェントに渡されて、そのMIME実体は通常、そうです。どこ、それはさらに解読されて、ユーザに提示されるか、またはアプリケーションを受け取っているか。
In order to protect outer, non-content related message headers (for instance, the "Subject", "To", "From" and "CC" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these headers. It is up to the receiving client to decide how to present these "inner" headers along with the unprotected "outer" headers.
外側の、そして、非内容の関連するメッセージヘッダー(例えば、「対象」、“To"、“From"、および「CC」分野)を保護して、送付クライアントは、S/MIMEセキュリティー・サービスをこれらのヘッダーに適用するためにメッセージ/rfc822ラッパーにおける完全なMIMEメッセージを包装するかもしれません。 保護のない「外側」のヘッダーに伴うこれらの「内側」のヘッダーを紹介する方法を決めるのは、受信クライアント次第です。
When an S/MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822, it can be assumed that the intent was to provide header protection. This entity SHOULD be presented as the top-level message, taking into account header merging issues as previously discussed.
S/MIMEメッセージが受信されているとき、トップレベルの保護されたMIME実体にメッセージ/rfc822のコンテントタイプがあるなら、意図がヘッダー保護を提供することであったと思うことができます。 トップレベルメッセージとして提示されて、アカウントヘッダー合併を連れていくと以前に議論しているとして発行されるこの実体SHOULD。
Ramsdell Standards Track [Page 15] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[15ページ]RFCメッセージ仕様2004年7月
3.1.1. Canonicalization
3.1.1. Canonicalization
Each MIME entity MUST be converted to a canonical form that is uniquely and unambiguously representable in the environment where the signature is created and the environment where the signature will be verified. MIME entities MUST be canonicalized for enveloping and compressing as well as signing.
署名が確かめられるところで署名が作成される環境と環境で唯一と明白に「表-可能」な標準形にそれぞれのMIME実体を変換しなければなりません。 署名と同様におおうのと圧縮のためにMIME実体をcanonicalizedしなければなりません。
The exact details of canonicalization depend on the actual MIME type and subtype of an entity, and are not described here. Instead, the standard for the particular MIME type SHOULD be consulted. For example, canonicalization of type text/plain is different from canonicalization of audio/basic. Other than text types, most types have only one representation regardless of computing platform or environment which can be considered their canonical representation. In general, canonicalization will be performed by the non-security part of the sending agent rather than the S/MIME implementation.
canonicalizationの正確な細部は、実体の実際のMIMEの種類と「副-タイプ」によって、ここで説明されません。 代わりに特定のMIMEの種類SHOULDの規格、相談されてください。 例えば、タイプテキスト/平野のcanonicalizationはオーディオ的か基本的のcanonicalizationと異なっています。 テキストタイプ以外に、ほとんどのタイプには、彼らの正準な表現であると考えることができるコンピューティングプラットホームか環境にかかわらず1つの表現しかありません。 一般に、canonicalizationはS/MIME実装よりむしろ送付エージェントの非セキュリティ部分によって実行されるでしょう。
The most common and important canonicalization is for text, which is often represented differently in different environments. MIME entities of major type "text" MUST have both their line endings and character set canonicalized. The line ending MUST be the pair of characters <CR><LF>, and the charset SHOULD be a registered charset [CHARSETS]. The details of the canonicalization are specified in [MIME-SPEC]. The chosen charset SHOULD be named in the charset parameter so that the receiving agent can unambiguously determine the charset used.
最も一般的で重要なcanonicalizationはテキストのためのものです。(それは、しばしば異なった環境で異なって表されます)。 主要なタイプ「テキスト」のMIME実体で、それらの系列結末と文字集合の両方をcanonicalizedしなければなりません。 系列結末はキャラクタ<CRの組が><LF>と、charset SHOULDであったなら登録されたcharsetが[CHARSETS]であったならそうしなければなりません。 canonicalizationの細部は[MIME-SPEC]で指定されます。 charset SHOULDが選ばれて、受信エージェントが、charsetが使用したと明白に決心できるように、charsetパラメタで命名されてください。
Note that some charsets such as ISO-2022 have multiple representations for the same characters. When preparing such text for signing, the canonical representation specified for the charset MUST be used.
ISO-2022などのいくつかのcharsetsには同じキャラクタにおいて複数の表現があることに注意してください。 署名のためにそのようなテキストを準備するとき、charsetに指定された正準な表現を使用しなければなりません。
3.1.2. Transfer Encoding
3.1.2. 転送コード化
When generating any of the secured MIME entities below, except the signing using the multipart/signed format, no transfer encoding is required at all. S/MIME implementations MUST be able to deal with binary MIME objects. If no Content-Transfer-Encoding header is present, the transfer encoding is presumed to be 7BIT.
複合の、または、署名している形式を使用する署名以外に、以下の機密保護しているMIME実体のどれかを生成するとき、転送コード化は全く必要ではありません。 S/MIME実装は2進のMIMEオブジェクトに対処できなければなりません。 どんなContentがコード化を移しているヘッダーも出席していないなら、転送コード化はあえて7BITです。
S/MIME implementations SHOULD however use transfer encoding described in section 3.1.3 for all MIME entities they secure. The reason for securing only 7-bit MIME entities, even for enveloped data that are not exposed to the transport, is that it allows the MIME entity to be handled in any environment without changing it. For example, a trusted gateway might remove the envelope, but not the signature, of a message, and then forward the signed message on to the end
しかしながら、S/MIME実装SHOULDはそれらが保証するすべてのMIME実体のためにセクション3.1.3で説明された転送コード化を使用します。 7ビットの唯一のMIMEが実体であると機密保護して、輸送に暴露されないおおわれたデータさえの理由はMIME実体がそれを変えないでどんな環境でも扱われるのを許容するということです。 例えば、信じられたゲートウェイは、署名ではなく、メッセージの封筒を取り外して、次に、署名しているメッセージを終わりに転送するかもしれません。
Ramsdell Standards Track [Page 16] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[16ページ]RFCメッセージ仕様2004年7月
recipient so that they can verify the signatures directly. If the transport internal to the site is not 8-bit clean, such as on a wide-area network with a single mail gateway, verifying the signature will not be possible unless the original MIME entity was only 7-bit data.
受取人、彼らが直接署名について確かめることができるように。 署名について確かめるのはオリジナルのMIME実体が7ビットのデータであっただけではないならサイトへの内部の輸送が8ビットでないなら、掃除してください、単一のメール・ゲートウェイがあるそのような同じくらいオン広域ネットワークが可能でないでしょう。
S/MIME implementations which "know" that all intended recipient(s) are capable of handling inner (all but the outermost) binary MIME objects SHOULD use binary encoding as opposed to a 7-bit-safe transfer encoding for the inner entities. The use of a 7-bit-safe encoding (such as base64) would unnecessarily expand the message size. Implementations MAY "know" that recipient implementations are capable of handling inner binary MIME entities either by interpreting the id-cap-preferBinaryInside sMIMECapabilities attribute, by prior agreement, or by other means.
すべての意図している受取人が2進でSHOULDが使用する内側(一番はずれを除いたすべて)の2進のMIMEオブジェクトを扱うことができるのを「知っている」7ビットの金庫と対照的にコード化されるS/MIME実装が内側の実体のためのコード化を移します。 7ビットの金庫コード化(base64などの)の使用は不必要にメッセージサイズを広くするでしょう。 実装は、受取人実装があらかじめ取り決めてイドがpreferBinaryInside sMIMECapabilitiesにふたををしている属性を解釈するか、他の手段で内側の2進のMIME実体を扱うことができるのを「知るかもしれません」。
If one or more intended recipients are unable to handle inner binary MIME objects, or if this capability is unknown for any of the intended recipients, S/MIME implementations SHOULD use transfer encoding described in section 3.1.3 for all MIME entities they secure.
1人以上の意図している受取人が内側の2進のMIMEオブジェクトを扱うことができないか、または意図している受取人のどれかにおいて、この能力が未知であるなら、S/MIME実装SHOULDはそれらが保証するすべてのMIME実体のためにセクション3.1.3で説明された転送コード化を使用します。
3.1.3. Transfer Encoding for Signing Using multipart/signed
3.1.3. Signing Usingのために複合か署名された状態でEncodingを移してください。
If a multipart/signed entity is ever to be transmitted over the standard Internet SMTP infrastructure or other transport that is constrained to 7-bit text, it MUST have transfer encoding applied so that it is represented as 7-bit text. MIME entities that are 7-bit data already need no transfer encoding. Entities such as 8-bit text and binary data can be encoded with quoted-printable or base-64 transfer encoding.
複合の、または、署名している実体がかつて7ビットのテキストに抑制される標準のインターネットSMTPインフラストラクチャか他の輸送の上に伝えられることであるなら、それで、7ビットのテキストとして表されるように転送コード化を適用しなければなりません。 7ビットのデータであるMIME実体は既に転送コード化を必要としません。 引用されて印刷可能で8ビットのテキストやバイナリ・データなどの実体をコード化できますか、またはベース-64はコード化を移します。
The primary reason for the 7-bit requirement is that the Internet mail transport infrastructure cannot guarantee transport of 8-bit or binary data. Even though many segments of the transport infrastructure now handle 8-bit and even binary data, it is sometimes not possible to know whether the transport path is 8-bit clean. If a mail message with 8-bit data were to encounter a message transfer agent that can not transmit 8-bit or binary data, the agent has three options, none of which are acceptable for a clear-signed message:
7ビットの要件のプライマリ理由はインターネット・メール輸送インフラが8ビットかバイナリ・データの輸送を保証できないということです。 輸送インフラの多くのセグメントが現在8ビットの、そして、同等のバイナリ・データを扱いますが、清潔な状態で輸送経路が8ビットであるかどうかを知るのは時々可能ではありません。 8ビットのデータがあるメール・メッセージが8ビットで伝わることができないメッセージ転送エージェントかバイナリ・データに遭遇することであったなら、エージェントには、3つのオプションがあります:はっきりと署名しているメッセージにおいて、そのいずれも許容できません。
- The agent could change the transfer encoding; this would
invalidate the signature.
- The agent could transmit the data anyway, which would most likely
result in the 8th bit being corrupted; this too would invalidate
the signature.
- The agent could return the message to the sender.
- エージェントは転送コード化を変えることができました。 これは署名を無効にするでしょう。 - エージェントはとにかくデータを送ることができました(たぶん崩壊する8番目のビットをもたらすでしょう)。 これも署名を無効にするでしょう。 - エージェントはメッセージを送付者に返すことができました。
Ramsdell Standards Track [Page 17] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[17ページ]RFCメッセージ仕様2004年7月
[MIME-SECURE] prohibits an agent from changing the transfer encoding of the first part of a multipart/signed message. If a compliant agent that can not transmit 8-bit or binary data encounters a multipart/signed message with 8-bit or binary data in the first part, it would have to return the message to the sender as undeliverable.
[MIME-SECURE]は複合の、または、署名しているメッセージの最初の部分の転送コード化を変えるのからエージェントを禁じます。 8ビットで伝わることができない言いなりになっているエージェントかバイナリ・データが最初の部分で8ビットかバイナリ・データで複合の、または、署名しているメッセージに遭遇するなら、それは「非-提出物」としてメッセージを送付者に返さなければならないでしょう。
3.1.4. Sample Canonical MIME Entity
3.1.4. 正準なMIME実体を抽出してください。
This example shows a multipart/mixed message with full transfer encoding. This message contains a text part and an attachment. The sample message text includes characters that are not US-ASCII and thus need to be transfer encoded. Though not shown here, the end of each line is <CR><LF>. The line ending of the MIME headers, the text, and transfer encoded parts, all MUST be <CR><LF>.
この例は完全移籍コード化で複合の、または、複雑なメッセージを示しています。 このメッセージはテキスト部分と付属を含んでいます。 サンプルメッセージ・テキストは米国-ASCIIでなく、その結果コード化された転送である必要があるキャラクタを含んでいます。 ここに示されませんが、それぞれの行の終わりは<CR><LF>です。 MIMEヘッダー、テキスト、および転送の系列結末は部品をコード化して、すべてが<CR><LF>であるに違いありません。
Note that this example is not of an S/MIME message.
この例がS/MIMEメッセージのものでないことに注意してください。
Content-Type: multipart/mixed; boundary=bar
コンテントタイプ: 複合か混ぜられる。 境界=バー
--bar
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
--コンテントタイプを禁じてください: テキスト/平野。 charset=iso-8859-1 Contentはコード化を移します: 引用されて印刷可能です。
=A1Hola Michael!
=A1Holaマイケル!
How do you like the new S/MIME specification?
新しいS/MIME仕様はいかがでしょうか?
It's generally a good idea to encode lines that begin with
From=20because some mail transport agents will insert a greater-
than (>) sign, thus invalidating the signature.
一般に、From=20becauseと共に何人かのメール輸送エージェントを始める系列をコード化するのが(>)よりすばらしいサインを挿入するのは、名案です、その結果、署名を無効にします。
Also, in some cases it might be desirable to encode any =20
trailing whitespace that occurs on lines in order to ensure =20
that the message signature is not invalidated when passing =20
a gateway that modifies such whitespace (like BITNET). =20
また、いくつかの場合、そのような空白(Bitnetのような)を変更するゲートウェイを=20に通り過ぎるとき、メッセージ署名が無効にされないのも、=20を確実にするために系列に起こるどんな=20引きずり空白もコード化するのにおいて望ましいかもしれません。 =20
--bar
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
--コンテントタイプを禁じてください: jpeg Content転送イメージ/コード化: base64
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI=
--bar--
--バー--
Ramsdell Standards Track [Page 18] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[18ページ]RFCメッセージ仕様2004年7月
3.2. The application/pkcs7-mime Type
3.2. pkcs7アプリケーション/パントマイムType
The application/pkcs7-mime type is used to carry CMS content types including EnvelopedData, SignedData, and CompressedData. The details of constructing these entities is described in subsequent sections. This section describes the general characteristics of the application/pkcs7-mime type.
pkcs7アプリケーション/パントマイムタイプは、EnvelopedData、SignedData、およびCompressedDataを含むCMS content typeを運ぶのに使用されます。 これらの実体を構成する詳細はその後のセクションで説明されます。 このセクションはpkcs7アプリケーション/パントマイムタイプの一般的特色について説明します。
The carried CMS object always contains a MIME entity that is prepared as described in section 3.1 if the eContentType is id-data. Other contents MAY be carried when the eContentType contains different values. See [ESS] for an example of this with signed receipts.
運ばれたCMSオブジェクトはいつもeContentTypeがイドデータであるならセクション3.1で説明されるように準備されたMIME実体を含んでいます。 eContentTypeが異価を含むとき、他のコンテンツは運ばれるかもしれません。 この例に関して署名している領収書で[ESS]を見てください。
Since CMS content types are binary data, in most cases base-64 transfer encoding is appropriate, in particular, when used with SMTP transport. The transfer encoding used depends on the transport through which the object is to be sent, and is not a characteristic of the MIME type.
CMS content typeがバイナリ・データであるので、多くの場合、ベース-64転送コード化は適切です、特に、SMTP輸送と共に使用されると。 コード化が使用した転送は、オブジェクトが送られることになっている輸送によって、MIMEの種類の特性ではありません。
Note that this discussion refers to the transfer encoding of the CMS object or "outside" MIME entity. It is completely distinct from, and unrelated to, the transfer encoding of the MIME entity secured by the CMS object, the "inside" object, which is described in section 3.1.
この議論がCMSオブジェクトか「外」のMIME実体の転送コード化について言及することに注意してください。 それは、転送がCMSオブジェクトによって保証されたMIME実体をコード化することでの“inside"オブジェクトに完全に異なって関係ありません。(それは、セクション3.1で説明されます)。
Because there are several types of application/pkcs7-mime objects, a sending agent SHOULD do as much as possible to help a receiving agent know about the contents of the object without forcing the receiving agent to decode the ASN.1 for the object. The MIME headers of all application/pkcs7-mime objects SHOULD include the optional "smime- type" parameter, as described in the following sections.
いくつかのタイプのpkcs7アプリケーション/パントマイムオブジェクトがあるので、SHOULDが受信エージェントにオブジェクトのためにASN.1を解読させないで受信エージェントがオブジェクトのコンテンツに関して知るのを助けるためにできるだけする送付エージェントです。 すべてのpkcs7アプリケーション/パントマイムオブジェクトSHOULDのMIMEヘッダーは以下のセクションで説明されるように任意の「smimeタイプ」パラメタを入れます。
3.2.1. The name and filename Parameters
3.2.1. 名前とファイル名Parameters
For the application/pkcs7-mime, sending agents SHOULD emit the optional "name" parameter to the Content-Type field for compatibility with older systems. Sending agents SHOULD also emit the optional Content-Disposition field [CONTDISP] with the "filename" parameter. If a sending agent emits the above parameters, the value of the parameters SHOULD be a file name with the appropriate extension:
pkcs7アプリケーション/パントマイムのために、送付エージェントSHOULDはパラメタという任意の「名前」をより古いシステムとの互換性のためのコンテントタイプ分野に放ちます。また、送付エージェントSHOULDは「ファイル名」パラメタがある任意のContent-気質分野[CONTDISP]を放ちます。 発信エージェントは上記のパラメタを放ちます、値。パラメタSHOULDでは、適切な拡大を伴うファイル名になってください:
Ramsdell Standards Track [Page 19] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[19ページ]RFCメッセージ仕様2004年7月
MIME Type File Extension
MIMEの種類ファイル拡張子
application/pkcs7-mime (SignedData, EnvelopedData) .p7m
pkcs7アプリケーション/パントマイム(SignedData、EnvelopedData).p7m
application/pkcs7-mime (degenerate SignedData .p7c
certificate management message)
pkcs7アプリケーション/パントマイム(堕落したSignedData .p7c証明書管理メッセージ)
application/pkcs7-mime (CompressedData) .p7z
pkcs7アプリケーション/パントマイム(CompressedData).p7z
application/pkcs7-signature (SignedData) .p7s
pkcs7アプリケーション/署名(SignedData).p7s
In addition, the file name SHOULD be limited to eight characters followed by a three letter extension. The eight character filename base can be any distinct name; the use of the filename base "smime" SHOULD be used to indicate that the MIME entity is associated with S/MIME.
さらに、存在という8つのキャラクタに制限されたファイル名のSHOULDは3手紙拡張子で続きました。 8キャラクタファイル名ベースはどんな別個の名前であるかもしれませんも。 ファイル名の使用は"smime"SHOULDを基礎づけます。使用されて、MIME実体がS/MIMEに関連しているのを示してください。
Including a file name serves two purposes. It facilitates easier use of S/MIME objects as files on disk. It also can convey type information across gateways. When a MIME entity of type application/pkcs7-mime (for example) arrives at a gateway that has no special knowledge of S/MIME, it will default the entity's MIME type to application/octet-stream and treat it as a generic attachment, thus losing the type information. However, the suggested filename for an attachment is often carried across a gateway. This often allows the receiving systems to determine the appropriate application to hand the attachment off to, in this case, a stand-alone S/MIME processing application. Note that this mechanism is provided as a convenience for implementations in certain environments. A proper S/MIME implementation MUST use the MIME types and MUST NOT rely on the file extensions.
ファイル名が2つの目的に役立つ包含。 それはディスクの上のファイルとしてS/MIMEオブジェクトの、より簡単な使用を容易にします。 また、それはゲートウェイの向こう側にタイプ情報を伝えることができます。 (例えば、)タイプpkcs7アプリケーション/パントマイムのMIME実体が到着すると、アプリケーション/への実体のMIMEの種類は、S/MIMEでは、デフォルトとするというどんな特別な知識も持っていないゲートウェイでは、八重奏で流れて、ジェネリック付属としてそれを扱います、その結果、タイプ情報を失います。 しかしながら、付属のための提案されたファイル名はゲートウェイの向こう側にしばしば運ばれます。 これはしばしば付属を渡すのが適切であるアプリケーションを決定する受電方式を許容します、この場合、スタンドアロンのS/MIME処理アプリケーション。 このメカニズムが実装のための便利としてある環境に提供されることに注意してください。 適切なS/MIME実装は、MIMEの種類を使用しなければならなくて、ファイル拡張子を当てにしてはいけません。
3.2.2. The smime-type parameter
3.2.2. smime-型引数
The application/pkcs7-mime content type defines the optional "smime- type" parameter. The intent of this parameter is to convey details about the security applied (signed or enveloped) along with information about the contained content. This specification defines the following smime-types.
pkcs7アプリケーション/パントマイムcontent typeは任意の「smimeタイプ」パラメタを定義します。 このパラメタの意図は含まれた内容の情報と共に適用された(署名されるか、またはおおわれます)セキュリティに関する詳細を伝えることです。 この仕様は以下のsmime-タイプを定義します。
Ramsdell Standards Track [Page 20] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[20ページ]RFCメッセージ仕様2004年7月
Name CMS type Inner Content
名前CMSはInner Contentをタイプします。
enveloped-data EnvelopedData id-data
おおわれたデータEnvelopedDataイドデータ
signed-data SignedData id-data
署名しているデータSignedDataイドデータ
certs-only SignedData none
本命だけSignedData、なし
compressed-data CompressedData id-data
圧縮されたデータCompressedDataイドデータ
In order for consistency to be obtained with future specifications, the following guidelines SHOULD be followed when assigning a new smime-type parameter.
一貫性が将来の仕様、以下のガイドラインSHOULDと共に得られる命令では、新しいsmime-型引数を割り当てるときには続かれてください。
1. If both signing and encryption can be applied to the content, then two values for smime-type SHOULD be assigned "signed-*" and "encrypted-*". If one operation can be assigned then this can be omitted. Thus since "certs-only" can only be signed, "signed-" is omitted.
1. smime-タイプSHOULDのために満足していて、当時の2つの値に署名と暗号化の両方を適用できるなら、「署名している*」と「暗号化された*」は割り当てられてください。 1つの操作を割り当てることができるなら、これを省略できます。 したがって、「本命専用」に署名することができるだけであるので、「署名すること」は省略されます。
2. A common string for a content OID SHOULD be assigned. We use "data" for the id-data content OID when MIME is the inner content.
2. aのための一般的なストリングはOID SHOULDを満足させます。割り当てられます。 MIMEが内側の内容であるときに、私たちはイドデータ内容OIDに「データ」を使用します。
3. If no common string is assigned. Then the common string of "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would be DES40).
3. どんな一般的なストリングも割り当てられないなら。 次に、「OID<oid>」の一般的なストリングがお勧めである、(例えば、「OID.1.3、.6、.1、.5、.5、.7、.6、0.1インチがDES40であるだろう、)、」
It is explicitly intended that this field be a suitable hint for mail client applications to indicate whether a message is "signed" or "encrypted" without having to tunnel into the CMS payload.
明らかに、この分野がメッセージがCMSペイロードにトンネルを堀る必要はなくて「署名される」か、または「暗号化されること」にかかわらずメールクライアントアプリケーションが示す適当なヒントであることを意図します。
3.3. Creating an Enveloped-only Message
3.3. 作成、おおわれて唯一のメッセージ
This section describes the format for enveloping a MIME entity without signing it. It is important to note that sending enveloped but not signed messages does not provide for data integrity. It is possible to replace ciphertext in such a way that the processed message will still be valid, but the meaning can be altered.
このセクションは、それに署名しないでMIME実体をおおうために形式について説明します。 おおわれますが、メッセージであることは署名されない発信がデータ保全に備えないことに注意するのが重要です。 処理メッセージがまだ有効になっていますが、意味を変更できるような方法で暗号文を取り替えるのは可能です。
Step 1. The MIME entity to be enveloped is prepared according to section 3.1.
1を踏んでください。 セクション3.1によると、おおわれるべきMIME実体は準備されます。
Step 2. The MIME entity and other required data is processed into a CMS object of type EnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content-encryption key SHOULD be encrypted for the originator and included in the EnvelopedData (see [CMS] Section 6).
2を踏んでください。 MIME実体と他の必要なデータはタイプEnvelopedDataのCMSオブジェクトに処理されます。 各受取人、満足している暗号化の主要なSHOULDのコピーに、主要な満足している暗号化のコピーを暗号化することに加えて、創始者のために暗号化されていて、EnvelopedDataで含められてください([CMS]セクション6を見てください)。
Ramsdell Standards Track [Page 21] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[21ページ]RFCメッセージ仕様2004年7月
Step 3. The EnvelopedData object is wrapped in a CMS ContentInfo object.
3を踏んでください。 EnvelopedDataオブジェクトはCMS ContentInfoオブジェクトで身を包まれます。
Step 4. The ContentInfo object is inserted into an application/pkcs7-mime MIME entity.
4を踏んでください。 ContentInfoオブジェクトはpkcs7アプリケーション/パントマイムMIME実体に挿入されます。
The smime-type parameter for enveloped-only messages is "enveloped- data". The file extension for this type of message is ".p7m".
おおわれて唯一のメッセージのためのsmime-型引数は「おおわれたデータ」です。 このタイプに関するメッセージのためのファイル拡張子は".p7m"です。
A sample message would be:
サンプルメッセージは以下の通りでしょう。
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
コンテントタイプ: pkcs7アプリケーション/パントマイム。 smime-タイプはおおわれたデータと等しいです。 =smime.p7m Content-転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名=smime.p7m
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V
3.4. Creating a Signed-only Message
3.4. aを作成する、署名されて唯一のメッセージ
There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents MUST be able to handle both.
S/MIMEのために定義された署名しているメッセージのための2つの形式があります: SignedDataがあるpkcs7アプリケーション/パントマイム、および複合/は署名しました。 一般に、複合の、または、署名しているフォームは送付のために好まれます、そして、エージェントを受けると、両方を扱うことができなければなりません。
3.4.1. Choosing a Format for Signed-only Messages
3.4.1. 署名されて唯一のメッセージのための形式を選びます。
There are no hard-and-fast rules when a particular signed-only format is chosen because it depends on the capabilities of all the receivers and the relative importance of receivers with S/MIME facilities being able to verify the signature versus the importance of receivers without S/MIME software being able to view the message.
事項であるときに、すべての受信機の能力とS/MIME施設がS/MIMEソフトウェアなしで受信機の重要性に対して署名について確かめることができる受信機の相対的な重要性によるので、署名されて唯一の形式が選ばれているというメッセージを見ることができるどんな厳重な規則もありません。
Messages signed using the multipart/signed format can always be viewed by the receiver whether they have S/MIME software or not. They can also be viewed whether they are using a MIME-native user agent or they have messages translated by a gateway. In this context, "be viewed" means the ability to process the message essentially as if it were not a signed message, including any other MIME structure the message might have.
それらにS/MIMEソフトウェアがあるか否かに関係なく、受信機はいつも複合の、または、署名している形式を使用することで署名されるメッセージを見ることができます。 また、彼らが固有のMIMEユーザエージェントを使用しているか否かに関係なく、それらを見ることができますか、または彼らはゲートウェイでメッセージを翻訳させます。 このような関係においては、「見られてください」はまるでそれが本質的には署名しているメッセージでないかのようにメッセージを処理する能力を意味します、メッセージが持っているかもしれないいかなる他のMIME構造も含んでいて。
Ramsdell Standards Track [Page 22] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[22ページ]RFCメッセージ仕様2004年7月
Messages signed using the SignedData format cannot be viewed by a recipient unless they have S/MIME facilities. However, the SignedData format protects the message content from being changed by benign intermediate agents. Such agents might do line wrapping or content-transfer encoding changes which would break the signature.
それらにS/MIME施設がないなら、受取人はSignedData形式を使用することで署名されるメッセージを見ることができません。 しかしながら、優しい仲介物質によって変えられるのからSignedData形式はメッセージ内容を保護します。 そのようなエージェントは、署名を壊す変化をコード化しながら、系列ラッピングか満足している転送をするかもしれません。
3.4.2. Signing Using application/pkcs7-mime with SignedData
3.4.2. SignedDataと共にUsingがpkcs7アプリケーション/パントマイムであると署名します。
This signing format uses the application/pkcs7-mime MIME type. The steps to create this format are:
この署名形式はpkcs7アプリケーション/パントマイムMIMEの種類を使用します。 この形式を作成するステップは以下の通りです。
Step 1. The MIME entity is prepared according to section 3.1.
1を踏んでください。 セクション3.1によると、MIME実体は準備されます。
Step 2. The MIME entity and other required data is processed into a CMS object of type SignedData.
2を踏んでください。 MIME実体と他の必要なデータはタイプSignedDataのCMSオブジェクトに処理されます。
Step 3. The SignedData object is wrapped in a CMS ContentInfo object.
3を踏んでください。 SignedDataオブジェクトはCMS ContentInfoオブジェクトで身を包まれます。
Step 4. The ContentInfo object is inserted into an application/pkcs7-mime MIME entity.
4を踏んでください。 ContentInfoオブジェクトはpkcs7アプリケーション/パントマイムMIME実体に挿入されます。
The smime-type parameter for messages using application/pkcs7-mime with SignedData is "signed-data". The file extension for this type of message is ".p7m".
SignedDataがあるpkcs7アプリケーション/パントマイムを使用するメッセージのためのsmime-型引数は「署名しているデータ」です。 このタイプに関するメッセージのためのファイル拡張子は".p7m"です。
A sample message would be:
サンプルメッセージは以下の通りでしょう。
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
コンテントタイプ: pkcs7アプリケーション/パントマイム。 smime-タイプは署名しているデータと等しいです。 =smime.p7m Content-転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh6YT64V0GhIGfHfQbnj75
3.4.3. Signing Using the multipart/signed Format
3.4.3. Usingが複合の、または、署名しているFormatであると署名します。
This format is a clear-signing format. Recipients without any S/MIME or CMS processing facilities are able to view the message. It makes use of the multipart/signed MIME type described in [MIME-SECURE]. The multipart/signed MIME type has two parts. The first part contains the MIME entity that is signed; the second part contains the "detached signature" CMS SignedData object in which the encapContentInfo eContent field is absent.
この形式は明確な署名形式です。 少しもS/MIMEやCMS処理施設のない受取人はメッセージを見ることができます。 それは[MIME-SECURE]で説明された複合の、または、署名しているMIMEの種類を利用します。 複合の、または、署名しているMIMEの種類には、2つの部品があります。 最初の部分は署名されるMIME実体を含んでいます。 第二部はencapContentInfo eContent分野が欠けている「離れている署名」CMS SignedDataオブジェクトを含んでいます。
Ramsdell Standards Track [Page 23] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[23ページ]RFCメッセージ仕様2004年7月
3.4.3.1. The application/pkcs7-signature MIME Type
3.4.3.1. pkcs7アプリケーション/署名MIMEの種類
This MIME type always contains a CMS ContentInfo containing a single CMS object of type SignedData. The SignedData encapContentInfo eContent field MUST be absent. The signerInfos field contains the signatures for the MIME entity.
このMIMEの種類はいつもタイプSignedDataの単一のCMSオブジェクトを含むCMS ContentInfoを含んでいます。 SignedData encapContentInfo eContent分野は欠けているに違いありません。 signerInfos分野はMIME実体のための署名を含んでいます。
The file extension for signed-only messages using application/pkcs7- signature is ".p7s".
アプリケーション/pkcs7署名を使用する署名されて唯一のメッセージのためのファイル拡張子は".p7s"です。
3.4.3.2. Creating a multipart/signed Message
3.4.3.2. 複合の、または、署名しているMessageを作成します。
Step 1. The MIME entity to be signed is prepared according to section 3.1, taking special care for clear-signing.
1を踏んでください。 明確な署名のために特別に注意を払って、セクション3.1によると、署名されるMIME実体は準備されます。
Step 2. The MIME entity is presented to CMS processing in order to obtain an object of type SignedData in which the encapContentInfo eContent field is absent.
2を踏んでください。 MIME実体は、encapContentInfo eContent分野が欠けているタイプSignedDataのオブジェクトを入手するためにCMS処理に提示されます。
Step 3. The MIME entity is inserted into the first part of a multipart/signed message with no processing other than that described in section 3.1.
3を踏んでください。 セクション3.1で説明されるのを除いて、MIME実体は処理なしで複合の、または、署名しているメッセージの最初の部分に挿入されます。
Step 4. Transfer encoding is applied to the "detached signature" CMS SignedData object and it is inserted into a MIME entity of type application/pkcs7-signature.
4を踏んでください。 転送コード化は「離れている署名」CMS SignedDataオブジェクトに適用されます、そして、それはタイプpkcs7アプリケーション/署名のMIME実体に挿入されます。
Step 5. The MIME entity of the application/pkcs7-signature is inserted into the second part of the multipart/signed entity.
5を踏んでください。 pkcs7アプリケーション/署名のMIME実体は複合の、または、署名している実体の第二部に挿入されます。
The multipart/signed Content type has two required parameters: the protocol parameter and the micalg parameter.
複合の、または、署名しているContentタイプには、2つの必要なパラメタがあります: プロトコルパラメタとmicalgパラメタ。
The protocol parameter MUST be "application/pkcs7-signature". Note that quotation marks are required around the protocol parameter because MIME requires that the "/" character in the parameter value MUST be quoted.
プロトコルパラメタは「pkcs7アプリケーション/署名」であるに違いありません。 「MIMEがそれを必要とするので引用符がプロトコルパラメタの周りで必要であることに注意してください、」 /、」 パラメタ値におけるキャラクタを引用しなければなりません。
The micalg parameter allows for one-pass processing when the signature is being verified. The value of the micalg parameter is dependent on the message digest algorithm(s) used in the calculation of the Message Integrity Check. If multiple message digest algorithms are used they MUST be separated by commas per [MIME- SECURE]. The values to be placed in the micalg parameter SHOULD be from the following:
署名が確かめられているとき、micalgパラメタは1パスの処理を考慮します。 micalgパラメタの値はMessage Integrity Checkの計算に使用されるメッセージダイジェストアルゴリズムに依存しています。 複数のメッセージダイジェストアルゴリズムが使用されているなら、[MIME SECURE]あたりのコンマでそれらを切り離さなければなりません。 micalgパラメタSHOULDに置かれるべき値は以下からの以下の通りです。
Ramsdell Standards Track [Page 24] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[24ページ]RFCメッセージ仕様2004年7月
Algorithm Value used
Valueが使用したアルゴリズム
MD5 md5
SHA-1 sha1
SHA-256 sha256
SHA-384 sha384
SHA-512 sha512
Any other (defined separately in algorithm profile or "unknown"
if not defined)
MD5 md5 SHA-1 sha1 SHA-256 sha256 SHA-384 sha384 SHA-512 sha512 Any他です。(別々にアルゴリズムプロフィールか「未知」で定義されるか、または定義されます)
(Historical note: some early implementations of S/MIME emitted and expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize.
そして、(歴史的な注意: S/MIMEのいくつかの早めの実装が放って、予想した、「rsa-md5"、「micalgパラメタのためのrsa-sha1")。」 エージェントSHOULDを受けて、彼らが認識しないmicalgパラメタ価値から優雅に回復できてください。
The SHA-256, SHA-384, and SHA-512 algorithms [FIPS180-2] are not currently recommended in S/MIME, and are included here for completeness.
SHA-256、SHA-384、およびSHA-512アルゴリズム[FIPS180-2]は、現在S/MIMEで推薦されないで、完全性のためにここに含まれています。
3.4.3.3. Sample multipart/signed Message
3.4.3.3. 複合の、または、署名しているMessageを抽出してください。
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
コンテントタイプ: 複合か署名される。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1。 境界=boundary42
--boundary42
Content-Type: text/plain
--boundary42コンテントタイプ: テキスト/平野
This is a clear-signed message.
これははっきりと署名しているメッセージです。
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
--boundary42コンテントタイプ: pkcs7アプリケーション/署名。 =smime.p7s Content-転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
--boundary42--
--boundary42--
Ramsdell Standards Track [Page 25] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[25ページ]RFCメッセージ仕様2004年7月
The content that is digested (the first part of the multipart/signed) are the bytes:
読みこなされているのが(複合か署名されることの最初の部分)、バイトであるということである内容:
43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
43 6f 6e74 65 6e74 2d54 79 70 65 3a20 74 65 78 74 2f70 6c61 69 6e 0d 0a 0d 0a54 68 69 73 20 69 73 20 61 20 63 6c65 61 72 2d73 69 67 6e65 64 20 6d65 73 73 61 67 65 2e 0d 0a
3.5. Creating an Compressed-only Message
3.5. 作成、圧縮されて唯一のメッセージ
This section describes the format for compressing a MIME entity. Please note that versions of S/MIME prior to 3.1 did not specify any use of CompressedData, and will not recognize it. The use of a capability to indicate the ability to receive CompressedData is described in [CMSCOMPR] and is the preferred method for compatibility.
このセクションは、MIME実体を圧縮するために形式について説明します。 3.1の前のS/MIMEのバージョンは、CompressedDataの少しの使用も指定しないで、またそれを認識しないでしょう。 CompressedDataを受け取る能力を示す能力の使用は、[CMSCOMPR]で説明されて、互換性のための適した方法です。
Step 1. The MIME entity to be compressed is prepared according to section 3.1.
1を踏んでください。 セクション3.1によると、圧縮されるべきMIME実体は準備されます。
Step 2. The MIME entity and other required data is processed into a CMS object of type CompressedData.
2を踏んでください。 MIME実体と他の必要なデータはタイプCompressedDataのCMSオブジェクトに処理されます。
Step 3. The CompressedData object is wrapped in a CMS ContentInfo object.
3を踏んでください。 CompressedDataオブジェクトはCMS ContentInfoオブジェクトで身を包まれます。
Step 4. The ContentInfo object is inserted into an application/pkcs7-mime MIME entity.
4を踏んでください。 ContentInfoオブジェクトはpkcs7アプリケーション/パントマイムMIME実体に挿入されます。
The smime-type parameter for compressed-only messages is "compressed-data". The file extension for this type of message is ".p7z".
圧縮されて唯一のメッセージのためのsmime-型引数は「圧縮されたデータ」です。 このタイプに関するメッセージのためのファイル拡張子は".p7z"です。
A sample message would be:
サンプルメッセージは以下の通りでしょう。
Content-Type: application/pkcs7-mime; smime-type=compressed-data;
name=smime.p7z
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7z
コンテントタイプ: pkcs7アプリケーション/パントマイム。 smime-タイプは圧縮されたデータと等しいです。 =smime.p7z Content-転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名=smime.p7z
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V
Ramsdell Standards Track [Page 26] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[26ページ]RFCメッセージ仕様2004年7月
3.6. Multiple Operations
3.6. 同時併行処理
The signed-only, encrypted-only, and compressed-only MIME formats can be nested. This works because these formats are all MIME entities that encapsulate other MIME entities.
署名されて唯一、暗号化されて唯一、および圧縮されて唯一のMIME書式を入れ子にすることができます。 これらの形式がすべて他のMIMEが実体であるとカプセル化するMIME実体であるので、これは働いています。
An S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME within reasonable resource limits of the recipient computer.
S/MIME実装は、受取人コンピュータの妥当なリソース限界の中で任意に入れ子にされたS/MIMEを、受けて、処理できなければなりません。
It is possible to apply any of the signing, encrypting, and compressing operations in any order. It is up to the implementer and the user to choose. When signing first, the signatories are then securely obscured by the enveloping. When enveloping first the signatories are exposed, but it is possible to verify signatures without removing the enveloping. This can be useful in an environment were automatic signature verification is desired, as no private key material is required to verify a signature.
順不同な操作を暗号化して、圧縮する署名のどれかを適用するのは可能です。 選ぶのは、implementerとユーザ次第です。 最初に署名すると、署名者はおおうことでしっかりと見えなくされます。 1番目をおおうとき、署名者は暴露されますが、おおうことを取り除かないで署名について確かめるのは可能です。 これによる環境で役に立つのが、自動署名照合は望まれています、秘密鍵の材料が全く署名について確かめるのに必要でないときにことであったということであることができます。
There are security ramifications to choosing whether to sign first or encrypt first. A recipient of a message that is encrypted and then signed can validate that the encrypted block was unaltered, but cannot determine any relationship between the signer and the unencrypted contents of the message. A recipient of a message that is signed-then-encrypted can assume that the signed message itself has not been altered, but that a careful attacker could have changed the unauthenticated portions of the encrypted message.
最初に、署名するか、または1番目を暗号化するかを選ぶことへのセキュリティ分岐があります。 非変更しましたが、暗号化されたブロックがそうであったという暗号化されていて、次に、署名されて、有効にされることができるメッセージの受取人はメッセージの署名者と非暗号化されたコンテンツとの少しの関係も決定できません。 その時暗号化されていた状態で署名されて、慎重な攻撃者が暗号化メッセージの非認証された部分を変えることができなかったなら署名しているメッセージ自体が変更されていないと仮定できるということであるメッセージの受取人。
When using compression, keep the following guidelines in mind:
圧縮を使用するときには、以下のガイドラインを覚えておいてください:
- Compression of binary encoded encrypted data is discouraged, since
it will not yield significant compression. Base64 encrypted data
could very well benefit, however.
- If a lossy compression algorithm is used with signing, you will
need to compress first, then sign.
- それが重要な圧縮をもたらさないので、2進のコード化された暗号化されたデータの要約はお勧めできないです。 しかしながら、暗号化されたデータは非常によく利益を得ることができました。Base64. --非可逆圧縮アルゴリズムが署名と共に使用されると、1番目を圧縮するのが必要であるだろう、次に、署名してください。
3.7. Creating a Certificate Management Message
3.7. 証明書管理メッセージを作成します。
The certificate management message or MIME entity is used to transport certificates and/or certificate revocation lists, such as in response to a registration request.
証明書管理メッセージかMIME実体が証明書、そして/または、証明書失効リストを輸送するのに使用されます、登録要求に対応してなど。
Step 1. The certificates and/or certificate revocation lists are made available to the CMS generating process which creates a CMS object of type SignedData. The SignedData encapContentInfo eContent field MUST be absent and signerInfos field MUST be empty.
1を踏んでください。 タイプSignedDataのCMSオブジェクトを作成するプロセスを生成するCMSは証明書、そして/または、証明書失効リストを入手します。 SignedData encapContentInfo eContent分野は欠けるに違いありません、そして、signerInfos分野は人影がないに違いありません。
Ramsdell Standards Track [Page 27] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[27ページ]RFCメッセージ仕様2004年7月
Step 2. The SignedData object is wrapped in a CMS ContentInfo object.
2を踏んでください。 SignedDataオブジェクトはCMS ContentInfoオブジェクトで身を包まれます。
Step 3. The ContentInfo object is enclosed in an application/pkcs7- mime MIME entity.
3を踏んでください。 ContentInfoオブジェクトはアプリケーション/pkcs7パントマイムMIME実体で同封されます。
The smime-type parameter for a certificate management message is "certs-only". The file extension for this type of message is ".p7c".
証明書管理メッセージのためのsmime-型引数は「本命専用」です。 このタイプに関するメッセージのためのファイル拡張子は".p7c"です。
3.8. Registration Requests
3.8. 登録要求
A sending agent that signs messages MUST have a certificate for the signature so that a receiving agent can verify the signature. There are many ways of getting certificates, such as through an exchange with a certificate authority, through a hardware token or diskette, and so on.
メッセージに署名する送付エージェントは、受信エージェントが署名について確かめることができるように、署名のための証明書を持たなければなりません。 証明書を手に入れる多くの方法があります、ハードウェアトークンかディスケットを通して認証局がある交換などなどのように。
S/MIME v2 [SMIMEV2] specified a method for "registering" public keys with certificate authorities using an application/pkcs10 body part. Since that time, the IETF PKIX Working Group has developed other methods for requesting certificates. However, S/MIME v3.1 does not require a particular certificate request mechanism.
S/MIME v2[SMIMEV2]は、認証局でアプリケーション/pkcs10身体の部分を使用することで「登録」公開鍵にメソッドを指定しました。 その時以来、IETF PKIX作業部会は証明書を要求するための他のメソッドを開発しています。 しかしながら、S/MIME v3.1は特定の証明書要求メカニズムを必要としません。
3.9. Identifying an S/MIME Message
3.9. S/MIMEメッセージを特定します。
Because S/MIME takes into account interoperation in non-MIME environments, several different mechanisms are employed to carry the type information, and it becomes a bit difficult to identify S/MIME messages. The following table lists criteria for determining whether or not a message is an S/MIME message. A message is considered an S/MIME message if it matches any of the criteria listed below.
S/MIMEが非MIME環境でinteroperationを考慮に入れるので、数個の異なったメカニズムがタイプ情報を運ぶのに使われます、そして、S/MIMEメッセージを特定するのは少し難しくなります。 以下のテーブルはメッセージがS/MIMEメッセージであるかどうか決定する評価基準を記載します。 以下に記載された評価基準のどれかを合わせるなら、メッセージはS/MIMEメッセージであると考えられます。
The file suffix in the table below comes from the "name" parameter in the content-type header, or the "filename" parameter on the content- disposition header. These parameters that give the file suffix are not listed below as part of the parameter section.
以下のテーブルのファイル接尾語はcontent typeヘッダーの「名前」パラメタ、または内容気質ヘッダーに関する「ファイル名」パラメタから来ます。 ファイル接尾語を与えるこれらのパラメタがパラメタ部の一部として以下にリストアップされていません。
MIME type: application/pkcs7-mime parameters: any file suffix: any
MIMEの種類: pkcs7アプリケーション/パントマイムパラメタ: どんなファイル接尾語も: いくらか
MIME type: multipart/signed parameters: protocol="application/pkcs7-signature" file suffix: any
MIMEの種類: 複合の、または、署名しているパラメタ: =「pkcs7アプリケーション/署名」ファイル接尾語について議定書の中で述べてください: いくらか
MIME type: application/octet-stream parameters: any file suffix: p7m, p7s, p7c, p7z
MIMEの種類: 八重奏アプリケーション/ストリームパラメタ: どんなファイル接尾語も: p7m、p7s、p7c、p7z
Ramsdell Standards Track [Page 28] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[28ページ]RFCメッセージ仕様2004年7月
4. Certificate Processing
4. 証明書処理
A receiving agent MUST provide some certificate retrieval mechanism in order to gain access to certificates for recipients of digital envelopes. This specification does not cover how S/MIME agents handle certificates, only what they do after a certificate has been validated or rejected. S/MIME certificate issues are covered in [CERT31].
受信エージェントは、デジタル封筒の受取人への証明書へのアクセスを得るために何らかの証明書回収機構を提供しなければなりません。 この仕様はS/MIMEエージェントがどう証明書を扱うかをカバーしていません、証明書が有効にされるか、または拒絶された後にそれらがすることだけ。 S/MIME証明書問題は[CERT31]でカバーされています。
At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message. Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval.
最小限では、初期のS/MIME展開のために、ユーザエージェントは自動的に署名しているリターンメッセージのその受取人の証明書を要求する意図している受取人にメッセージを生成することができました。 また、エージェントSHOULDを受けて、送ると、メカニズムは、彼らの後の検索を保証するためにユーザが通信員のためにそのような方法で証明書を「保存して、保護すること」を許容するために提供されます。
4.1. Key Pair Generation
4.1. 主要な組世代
All generated key pairs MUST be generated from a good source of non- deterministic random input [RANDOM] and the private key MUST be protected in a secure fashion.
非決定論的な無作為の入力[RANDOM]の良い源から主要な組であると生成されたすべてを生成しなければなりません、そして、安全なファッションで秘密鍵を保護しなければなりません。
If an S/MIME agent needs to generate an RSA key pair, then the S/MIME agent or some related administrative utility or function SHOULD generate RSA key pairs using the following guidelines. A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits. A user agent MUST NOT generate RSA key pairs less than 512 bits long. Creating keys longer than 1024 bits can cause some older S/MIME receiving agents to not be able to verify signatures, but gives better security and is therefore valuable. A receiving agent SHOULD be able to verify signatures with keys of any size over 512 bits. Some agents created in the United States have chosen to create 512 bit keys in order to get more advantageous export licenses. However, 512 bit keys are considered by many to be cryptographically insecure. Implementers SHOULD be aware that multiple (active) key pairs can be associated with a single individual. For example, one key pair can be used to support confidentiality, while a different key pair can be used for authentication.
S/MIMEエージェントが、RSA主要な組を生成する必要があるなら、S/MIMEエージェントか或るものが管理ユーティリティについて話したか、または機能SHOULDは、以下のガイドラインを使用することでRSA主要な組を生成します。 SHOULDがRSAキーを生成するユーザエージェントは最低768ビットの主要なサイズで対にします。 ユーザエージェントは長さ512ビットのRSA主要な組を生成してはいけません。 1024ビットより長い間キーを作成するのは、エージェントを受ける何らかのより古いS/MIMEが署名について確かめることができないことを引き起こす場合がありますが、より良いセキュリティを与えて、したがって、貴重です。 エージェントSHOULDを受けて、どんな512ビット以上のサイズのキーによる署名についても確かめることができてください。 合衆国で創造されたエージェントの中には、より有利な輸出承認を得るために512ビットのキーを作成するのを選んだ人もいました。 しかしながら、512ビットのキーは多くによって暗号で不安定な状態で考えられます。 Implementers SHOULD、複数の(アクティブ)の主要な組を単独の個人に関連づけることができるのを意識してください。 例えば、秘密性をサポートするのに主要な1組を使用できます、認証に異なった主要な組を使用できますが。
5. Security Considerations
5. セキュリティ問題
40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of tripleDES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is
40ビットの暗号化は弱いとほとんどの暗号使用者によって考えられます。 S/MIMEに弱い暗号を使用するのはほとんど送付平文の上に実際のセキュリティを提供しません。 しかしながら、tripleDESの仕様などのS/MIMEの他の特徴とあなたと交信するパーティーへの、より強い暗号の能力を発表する能力で、送付者は強い暗号化を使用するメッセージを作成できます。 唯一の選択肢がお勧めでないなら、弱い暗号を使用するのは決してお勧めではありません。
Ramsdell Standards Track [Page 29] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[29ページ]RFCメッセージ仕様2004年7月
no cryptography. When feasible, sending and receiving agents SHOULD inform senders and recipients of the relative cryptographic strength of messages.
暗号がありません。 可能であるときに、送受信エージェントSHOULDはメッセージの相対的な暗号の強さについて送付者と受取人に知らせます。
It is impossible for most software or people to estimate the value of a message. Further, it is impossible for most software or people to estimate the actual cost of decrypting a message that is encrypted with a key of a particular size. Further, it is quite difficult to determine the cost of a failed decryption if a recipient cannot decode a message. Thus, choosing between different key sizes (or choosing whether to just use plaintext) is also impossible. However, decisions based on these criteria are made all the time, and therefore this specification gives a framework for using those estimates in choosing algorithms.
ほとんどのソフトウェアか人々がメッセージの値を見積もっているのは、不可能です。 さらに、ほとんどのソフトウェアか人々が、メッセージがそれであると解読する実費が特定のサイズのキーで暗号化されると見積もっているのは、不可能です。 さらに、受取人が暗号文を普通文に直すことができないなら、失敗した復号化の費用を決定するのはかなり難しいです。 また、したがって、異なった主要なサイズ(ただ平文を使用するかどうかを選んで)を選ぶのも不可能です。 しかしながら、絶えずこれらの評価基準に基づく決定をします、そして、したがって、この仕様はアルゴリズムを選ぶ際にそれらの見積りを使用するためにフレームワークを与えます。
If a sending agent is sending the same message using different strengths of cryptography, an attacker watching the communications channel might be able to determine the contents of the strongly- encrypted message by decrypting the weakly-encrypted version. In other words, a sender SHOULD NOT send a copy of a message using weaker cryptography than they would use for the original of the message.
送付エージェントが暗号の異なった強さを使用することで同じメッセージを送るなら、コミュニケーションチャンネルを監視している攻撃者は、弱々しく暗号化されたバージョンを解読することによって、強く暗号化されたメッセージのコンテンツを決定できるかもしれません。 言い換えれば、SHOULD NOTが彼らがメッセージのオリジナルに使用するだろうより弱い暗号を使用するメッセージのコピーを送る送付者。
Modification of the ciphertext can go undetected if authentication is not also used, which is the case when sending EnvelopedData without wrapping it in SignedData or enclosing SignedData within it.
また、認証(SignedDataでそれを包装するか、またはそれの中にSignedDataを同封しないでEnvelopedDataを送るとき、ケースである)が使用されないなら、暗号文の変更は察知されずにいることができます。
See RFC 3218 [MMA] for more information about thwarting the adaptive chosen ciphertext vulnerability in PKCS #1 Version 1.5 implementations.
PKCS#で適応型の選ばれた暗号文脆弱性を阻んで、周囲で詳しい情報のためのRFC3218[MMA]を見てください。1つのバージョンの1.5の実装。
In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. These methods are described in RFC 2785 [DHSUB].
いくつかの事情では、大きい第1pの主要なオーダーサブグループにおけるディフィー-ヘルマンの主要な協定体系の使用は「小さいサブグループ」攻撃として知られているある攻撃に被害を受け易いです。 メソッドは、しかしながら、これらの攻撃を防ぐために存在しています。 これらのメソッドはRFC2785[DHSUB]で説明されます。
Ramsdell Standards Track [Page 30] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[30ページ]RFCメッセージ仕様2004年7月
A. ASN.1 Module
A。 ASN.1モジュール
SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
SecureMimeMessageV3dot1iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)msg-v3dot1(21)
DEFINITIONS IMPLICIT TAGS ::= BEGIN
定義、内在しているタグ:、:= 始まってください。
IMPORTS
-- Cryptographic Message Syntax
SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
IMPORTS--暗号のMessage Syntax SubjectKeyIdentifier、IssuerAndSerialNumber、RecipientKeyIdentifier FROM CryptographicMessageSyntax、iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-2001(14)、。
-- id-aa is the arc with all new authenticated and unauthenticated -- attributes produced the by S/MIME Working Group
-- 認証されて、非認証されて、イド-aaはすべてが新しいアークです--属性が作り出された、S/MIME作業部会
id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
イド-aa OBJECT IDENTIFIER:、:= iso(1)メンバーボディー(2)usa(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)は(2)を結果と考えます。
-- S/MIME Capabilities provides a method of broadcasting the symmetric -- capabilities understood. Algorithms SHOULD be ordered by -- preference and grouped by type
-- S/MIME Capabilitiesは左右対称を放送するメソッドを提供します--能力は分かりました。 アルゴリズムSHOULD、注文されてください--、好みであってタイプによって分類にされる
smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
smimeCapabilitiesオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9)15をメンバーと同じくらい具体化させます。
SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL }
SMIMECapability:、:= 系列capabilityID OBJECT IDENTIFIER、パラメタいずれもDEFINED BY capabilityID OPTIONAL
SMIMECapabilities ::= SEQUENCE OF SMIMECapability
SMIMECapabilities:、:= SMIMECapabilityの系列
-- Encryption Key Preference provides a method of broadcasting the -- preferred encryption certificate.
-- 暗号化Key Preferenceが放送のメソッドを提供する、--都合のよい暗号化証明書。
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
イド-aa-encrypKeyPrefオブジェクト識別子:、:= イド-aa11
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}
SMIMEEncryptionKeyPreference:、:= 選択issuerAndSerialNumber[0]IssuerAndSerialNumber、receipentKeyId[1]RecipientKeyIdentifier、subjectAltKeyIdentifier[2]SubjectKeyIdentifier
Ramsdell Standards Track [Page 31] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[31ページ]RFCメッセージ仕様2004年7月
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
イド-smime OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9)16をメンバーと同じくらい具体化させます。
id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
イド上限OBJECT IDENTIFIER:、:= イド-smime11
-- The preferBinaryInside indicates an ability to receive messages -- with binary encoding inside the CMS wrapper
-- preferBinaryInsideはCMSラッパーにおける2進のコード化でメッセージを受け取る能力を示します。
id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
イドがpreferBinaryInsideにふたををしているオブジェクト識別子:、:= イド上限1
-- The following list the OIDs to be used with S/MIME V3
-- 以下は、S/MIME V3と共に使用されるためにOIDsを記載します。
-- Signature Algorithms Not Found in [CMSALG]
--
-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 2}
--
-- Other Signed Attributes
--
-- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5}
-- See [CMS] for a description of how to encode the attribute
-- value.
-- [CMSALG]で見つけられなかった署名アルゴリズム----md2WithRSAEncryptionオブジェクト識別子:、:= -- iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-1(1)--、2、--、--他のSigned Attributes----、signingTime OBJECT IDENTIFIER:、:= -- iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-9(9)--、5、--どう属性をコード化するかに関する記述に関して[CMS]を見てください--値
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER -- (RC2 Key Length (number of bits))
SMIMECapabilitiesParametersForRC2CBC:、:= 整数--(RC2 Key Length(ビットの数))
END
終わり
B. References
B。 参照
B.1. Normative References
B.1。 引用規格
[CERT31] Ramsdell, B., Ed., "S/MIME Version 3.1 Certificate
Handling", RFC 3850, July 2004.
[CERT31] エドRamsdell、B.、RFC3850、「S/MIMEバージョン3.1証明書は扱う」7月2004日
[CHARSETS] Character sets assigned by IANA. See
http://www.iana.org/assignments/character-sets
IANAによって割り当てられた[CHARSETS]文字集合。 http://www.iana.org/assignments/character-sets を見てください。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
(AES) Encryption Algorithm in Cryptographic Message
Syntax (CMS)", RFC 3565, July 2003.
[CMSAES]Schaad、J.、「暗号のメッセージ構文(cm)におけるエー・イー・エス(AES)暗号化アルゴリズムの使用」、RFC3565(2003年7月)。
Ramsdell Standards Track [Page 32] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[32ページ]RFCメッセージ仕様2004年7月
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMSALG] Housley、R.、「暗号のメッセージ構文(cm)アルゴリズム」、RFC3370、2002年8月。
[CMSCOMPR] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, June
2002.
[CMSCOMPR] ガットマン、P.、「暗号のメッセージ構文(cm)のための圧縮されたデータcontent type」、RFC3274、2002年6月。
[CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August
1997.
[CONTDISP] Troost、R.、デルナー、S.、およびK.ムーア、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「満足している気質ヘッダーフィールド」、RFC2183、1997年8月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[ESS]ホフマン、P.、「S/MIMEのための警備の強化サービス」、RFC2634、1999年6月。
[FIPS180-2] "Secure Hash Signature Standard (SHS)", National
Institute of Standards and Technology (NIST). FIPS
Publication 180-2.
[FIPS180-2]「安全なハッシュ署名規格(SHS)」、米国商務省標準技術局(NIST)。 FIPS公表180-2。
[MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
解放された[MIME仕様]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996.
N.とN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
N.、Klensin、J.、およびJ.ポステル、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、BCP13、RFC2048、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance Criteria
and Examples", RFC 2049, November 1996.
N.とN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は5を分けます」。 「順応評価基準と例」、RFC2049、11月1996日
[MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[MIME安全な] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「サインされて複合の/がコード化した複合/」、RFC1847、1995年10月。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
[X.208-88]CCITT。 推薦X.208: 抽象構文記法1(ASN.1)の仕様。 1988.
Ramsdell Standards Track [Page 33] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[33ページ]RFCメッセージ仕様2004年7月
[X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One
(ASN.1). 1988.
[X.209-88]CCITT。 推薦X.209: 基本的なコード化の仕様は抽象構文記法1(ASN.1)のために統治されます。 1988.
[X.509-88] CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988.
[X.509-88]CCITT。 推薦X.509: ディレクトリ--認証枠組み。 1988.
B.2. Informative References
B.2。 有益な参照
[DHSUB] Zuccherato, R., "Methods for Avoiding the "Small-
Subgroup" Attacks on the Diffie-Hellman Key Agreement
Method for S/MIME", RFC 2785, March 2000.
[DHSUB] Zuccherato、R.、「S/MIMEのためにディフィー-ヘルマンの主要な協定方法に対する「小さいサブグループ」攻撃を避けるための方法」、RFC2785(2000年3月)。
[MMA] Rescorla, E., "Preventing the Million Message Attack on
Cryptographic Message Syntax", RFC 3218, January 2002.
[MMA]レスコラ、E.、「暗号のメッセージ構文に対する100万メッセージ攻撃を防ぎます」、RFC3218、2002年1月。
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, March 1998.
[PKCS-7]Kaliski、B.、「PKCS#7:」 暗号のメッセージ構文バージョン1.5インチ、RFC2315、1998年3月。
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
イーストレーク[無作為]の3番目、D.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性推薦」RFC1750、1994年12月。
[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L.,
and L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, March 1998.
[SMIMEV2] Dusse、S.、ホフマン、P.、Ramsdell、B.、Lundblade、L.、およびL.Repka、「S/MIMEバージョン2メッセージ仕様」、RFC2311(1998年3月)。
Ramsdell Standards Track [Page 34] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[34ページ]RFCメッセージ仕様2004年7月
C. Acknowledgements
C。 承認
Many thanks go out to the other authors of the S/MIME Version 2 Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Lundblade and Lisa Repka.
許可していた状態で、S/MIMEバージョン2Message Specification RFCの他の作者への外でありがとうございます: スティーブDusse、ポール・ホフマン、ローレンスLundblade、およびリサRepka。
A number of the members of the S/MIME Working Group have also worked very hard and contributed to this document. Any list of people is doomed to omission, and for that I apologize. In alphabetical order, the following people stand out in my mind due to the fact that they made direct contributions to this document.
S/MIME作業部会の多くのメンバーが、また、一生懸命仕事して、このドキュメントに貢献しました。 人々のどんなリストも省略に運命づけられます、そして、それを、私は謝ります。 彼らが直接的な貢献をこのドキュメントにしたという事実のため、アルファベット順に、以下の人々は私の心で際立っています。
Tony Capel Piers Chivers Dave Crocker Bill Flanigan Peter Gutmann Paul Hoffman Russ Housley William Ottaway John Pawling Jim Schaad
トニーケープル埠頭のシバーズデーヴ医者ビルフラニガンピーターガットマンポールホフマンラスHousleyウィリアムOttawayジョンPawlingジムSchaad
D. Editor's Address
D。 エディタのアドレス
Blake Ramsdell Sendmail, Inc. 704 228th Ave NE #775 Sammamish, WA 98074
ブレークRamsdellセンドメールInc.704第228Ave Ne#775サマミシュ、ワシントン 98074
EMail: blake@sendmail.com
メール: blake@sendmail.com
Ramsdell Standards Track [Page 35] RFC 3851 S/MIME 3.1 Message Specification July 2004
3851秒間/MIME3.1のRamsdell標準化過程[35ページ]RFCメッセージ仕様2004年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). 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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ramsdell Standards Track [Page 36]
Ramsdell標準化過程[36ページ]
一覧
スポンサーリンク
