[要約] RFC 5751は、電子メールの内容を暗号化・署名するための標準規格「S/MIME」のバージョン3.2におけるメッセージ形式を定義しています。CMS（Cryptographic Message Syntax）を用いたデータのカプセル化、MIMEタイプ（application/pkcs7-mimeなど）の使用方法、および暗号アルゴリズムの最小要件を規定し、安全なメール通信の基盤を提供します（RFC 3851の後継、後にRFC 8551に更新されました）。
Internet Engineering Task Force (IETF) B. Ramsdell
Request for Comments: 5751 Brute Squad Labs
Obsoletes: 3851 S. Turner
Category: Standards Track IECA
ISSN: 2070-1721 January 2010
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
セキュア/多目的インターネットメール拡張（S/MIME）バージョン3.2メッセージ仕様
Abstract
概要
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. 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 3851.
この文書はSecure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2を定めます。S/MIMEは、安全なMIMEデータを一貫した方法で送受信できるようにします。デジタル署名は、認証、メッセージ完全性、および送信元証明を伴う否認防止を実現します。暗号化はデータの機密性を確保し、圧縮はデータ量の削減に利用できます。この文書はRFC 3851を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
この文書はIETF（Internet Engineering Task Force）の成果であり、IETFコミュニティの合意を示しています。公開レビューを受け、Internet Engineering Steering Group（IESG）によって発行が承認されました。インターネット標準に関する詳細はRFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5751.
この文書の現在の状態、エラッタ、およびフィードバックの提供方法は、http://www.rfc-editor.org/info/rfc5751 で確認できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、発行日に有効なBCP 78およびIETF文書に関するIETF Trustの法的規定（http://trustee.ietf.org/license-info）の対象です。これらの文書には、この文書に関する権利と制限が記載されているため、よく確認してください。この文書から抽出したコードコンポーネントには、Trustの法的規定のセクション4.eに記載されたSimplified BSD Licenseの文面を含める必要があり、同ライセンスに記載のとおり無保証で提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008年11月10日より前に公開または一般公開されたIETF文書やIETFへの寄稿物の内容が含まれている場合があります。そうした内容の一部については、著作権者がIETF Trustに対し、IETF標準化プロセス外での改変を許可する権利を付与していない可能性があります。著作権者から適切なライセンスを得ない限り、この文書をIETF標準化プロセス外で改変したり、その派生物を作成したりしてはなりません。ただし、RFCとして公開するための形式調整、および英語以外の言語への翻訳は例外です。
Table of Contents
目次
1. Introduction ....................................................4 1.1. Specification Overview .....................................4 1.2. Definitions ................................................5 1.3. Conventions Used in This Document ..........................6 1.4. Compatibility with Prior Practice of S/MIME ................7 1.5. Changes from S/MIME v3 to S/MIME v3.1 ......................7 1.6. Changes since S/MIME v3.1 ..................................7 2. CMS Options .....................................................9 2.1. DigestAlgorithmIdentifier ..................................9 2.2. SignatureAlgorithmIdentifier ...............................9 2.3. KeyEncryptionAlgorithmIdentifier ..........................10 2.4. General Syntax ............................................11 2.5. Attributes and the SignerInfo Type ........................12 2.6. SignerIdentifier SignerInfo Type ..........................16 2.7. ContentEncryptionAlgorithmIdentifier ......................16 3. Creating S/MIME Messages .......................................18 3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing ............................................19 3.2. The application/pkcs7-mime Media Type .....................23 3.3. Creating an Enveloped-Only Message ........................25 3.4. Creating a Signed-Only Message ............................26 3.5. Creating a Compressed-Only Message ........................30 3.6. Multiple Operations .......................................30 3.7. Creating a Certificate Management Message .................31 3.8. Registration Requests .....................................32 3.9. Identifying an S/MIME Message .............................32 4. Certificate Processing .........................................32 4.1. Key Pair Generation .......................................33 4.2. Signature Generation ......................................33 4.3. Signature Verification ....................................34 4.4. Encryption ................................................34 4.5. Decryption ................................................34 5. IANA Considerations ............................................34 5.1. Media Type for application/pkcs7-mime .....................34 5.2. Media Type for application/pkcs7-signature ................35 6. Security Considerations ........................................36 7. References .....................................................38 7.1. Reference Conventions .....................................38 7.2. Normative References ......................................39 7.3. Informative References ....................................41 Appendix A. ASN.1 Module ..........................................43 Appendix B. Moving S/MIME v2 Message Specification to Historic Status ................................................45 Appendix C. Acknowledgments .......................................45
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). As a supplementary service, S/MIME provides for message compression.
S/MIME（Secure/Multipurpose Internet Mail Extensions）は、安全なMIMEデータを一貫した方法で送受信できるようにします。広く使われるインターネット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 or SIP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems.
S/MIMEは従来のメールユーザーエージェント（MUA）で利用でき、送信メールに暗号学的セキュリティ機能を追加したり、受信メールのセキュリティ機能を解釈したりできます。ただし、S/MIMEの用途はメールに限られません。HTTPやSIPなど、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メッセージの暗号化など、人間の介入を必要としない暗号化セキュリティサービスを使用する自動化されたメッセージ転送エージェントで使用できます。
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 of Internet messages and allows extensions for new content-type-based applications.
この文書では、MIMEデータに暗号学的な署名機能と暗号化機能を追加するプロトコルを説明します。MIME標準[MIME-SPEC]はインターネットメッセージの内容を構成する一般的な枠組みを定め、新しいコンテンツタイプに基づくアプリケーションへの拡張を可能にします。
This specification defines how to create a MIME body part that has been cryptographically enhanced according to the Cryptographic Message Syntax (CMS) RFC 5652 [CMS], which is derived from PKCS #7 [PKCS-7]. This specification also defines the application/pkcs7-mime media type that can be used to transport those body parts.
この仕様では、PKCS #7 [PKCS-7]から派生したCryptographic Message Syntax（CMS）RFC 5652 [CMS]に従って、暗号学的な保護を施したMIMEボディパートを作成する方法を定めます。また、そのボディパートの転送に使えるapplication/pkcs7-mimeメディアタイプも定めます。
This document also discusses how to use the multipart/signed media type defined in [MIME-SECURE] to transport S/MIME signed messages. multipart/signed is used in conjunction with the application/pkcs7- signature media type, which is used to transport a detached S/MIME signature.
この文書では、[MIME-SECURE]で定義されたmultipart/signedメディアタイプを使ってS/MIME署名付きメッセージを転送する方法も説明します。multipart/signedは、取り外し可能なS/MIME署名を運ぶapplication/pkcs7-signatureメディアタイプと組み合わせて使います。
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], [RSAPSS], [RSAOAEP], and [CMS-SHA2].
S/MIMEメッセージを作成するには、S/MIMEエージェントがこのドキュメントの仕様と、暗号化メッセージSyntax Document [CMS]、[CMSALG]、[RSAPSS]、[RSAOAEP]にリストされている仕様に従わなければなりません (MUST)。および[CMS-Sha2]。
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システムが存在する可能性からも派生しています。S/MIMEは、MIMEデータを輸送する任意のシステムで使用できます。暗号化されたメッセージを送信する自動化されたプロセスでは、たとえば、暗号化されたメッセージをまったく受信できない場合があります。したがって、2種類のエージェントの要件と推奨事項は、必要に応じて個別にリストされます。
For the purposes of this specification, the following definitions apply.
この仕様の目的のために、次の定義が適用されます。
ASN.1: Abstract Syntax Notation One, as defined in ITU-T Recommendation X.680 [X.680].
ASN.1：ITU-T Recommendation X.680 [X.680]で定義されるAbstract Syntax Notation One。
BER: Basic Encoding Rules for ASN.1, as defined in ITU-T Recommendation X.690 [X.690].
BER：ITU-T Recommendation X.690 [X.690]で定義されるASN.1のBasic 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 ITU-T Recommendation X.690 [X.690].
DER：ITU-T Recommendation X.690 [X.690]で定義されるASN.1のDistinguished 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コンテンツタイプを含むMIMEボディパーツ、またはその両方を解釈および処理するソフトウェア。
Sending agent: Software that creates S/MIME CMS content types, MIME body parts that contain CMS content types, or both.
送信エージェント：S/MIME CMSコンテンツタイプ、CMSコンテンツタイプを含むMIMEボディパーツ、またはその両方を作成するソフトウェア。
S/MIME agent: User software that is a receiving agent, a sending agent, or both.
S/MIMEエージェント：受信エージェント、送信エージェント、またはその両方であるユーザーソフトウェア。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」というキーワードは、すべて大文字で記されている場合に限り、[MUSTSHOULD]で説明される意味で解釈します。
We define some additional terms here:
ここでは、いくつかの追加の用語を定義します。
SHOULD+ This term means the same as SHOULD. However, the authors expect that a requirement marked as SHOULD+ will be promoted at some future time to be a MUST.
SHOULD+ はSHOULDと同じ意味です。ただし、著者らは、SHOULD+とされた要件を将来MUSTに引き上げることを想定しています。
SHOULD- This term means the same as SHOULD. However, the authors expect that a requirement marked as SHOULD- will be demoted to a MAY in a future version of this document.
SHOULD- はSHOULDと同じ意味です。ただし、著者らは、SHOULD-とされた要件をこの文書の将来版でMAYに引き下げることを想定しています。
MUST- This term means the same as MUST. However, the authors expect that this requirement will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST-requirement, it will remain at least a SHOULD or a SHOULD-.
MUST- はMUSTと同じ意味です。ただし、著者らは、将来の文書ではこの要件がMUSTではなくなると想定しています。位置付けは後日決まりますが、将来の改訂でMUST-要件の位置付けが変更されても、少なくともSHOULDまたはSHOULD-のレベルにとどまると考えるのが妥当です。
S/MIME version 3.2 agents ought to 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 [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive and RFC 5035 [SMIMEv3], and S/MIME version 3.1 is described in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1]. RFC 2311 also has historical information about the development of S/MIME.
S/MIMEバージョン3.2のエージェントは、以前のバージョンのエージェントと可能な限り高い相互運用性を実現するよう努めるべきです。S/MIMEバージョン2はRFC 2311からRFC 2315まで（両端を含む）[SMIMEv2]、バージョン3はRFC 2630からRFC 2634まで（両端を含む）およびRFC 5035 [SMIMEv3]、バージョン3.1はRFC 3850、RFC 3851、RFC 3852、RFC 2634、およびRFC 5035 [SMIMEv3.1]で説明されています。RFC 2311にはS/MIMEの開発に関する歴史的情報も記載されています。
The RSA public key algorithm was changed to a MUST implement key wrapping algorithm, and the Diffie-Hellman (DH) algorithm changed to a SHOULD implement.
RSA公開鍵アルゴリズムはMUSTレベルの鍵ラップアルゴリズムに変更され、Diffie-Hellman（DH）アルゴリズムは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公開鍵アルゴリズムが、MUSTレベルの署名アルゴリズムに変更されました。
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メッセージを使う場合の曖昧な記述を、Certificate Revocation Lists（CRL）も転送できることが反映されるよう明確化しました。
The use of binary encoding for some MIME entities is now explicitly discussed.
一部のMIMEエンティティのバイナリエンコーディングの使用については、現在明示的に議論されています。
Header protection through the use of the message/rfc822 media type has been added.
message/rfc822メディアタイプの使用によるヘッダー保護が追加されました。
Use of the CompressedData CMS type is allowed, along with required media type and file extension additions.
必要なメディアタイプとファイル拡張子の追加とともに、CompressedData CMSタイプも使用できるようになりました。
Editorial changes, e.g., replaced "MIME type" with "media type", content-type with Content-Type.
編集上の変更として、たとえば「MIME type」を「media type」に、「content-type」を「Content-Type」に置き換えました。
Moved "Conventions Used in This Document" to Section 1.3. Added definitions for SHOULD+, SHOULD-, and MUST-.
「Conventions Used in This Document」をセクション1.3へ移動し、SHOULD+、SHOULD-、MUST-の定義を追加しました。
Section 1.1 and Appendix A: Added references to RFCs for RSASSA-PSS, RSAES-OAEP, and SHA2 CMS algorithms. Added CMS Multiple Signers Clarification to CMS reference.
セクション1.1および付録Aに、RSASSA-PSS、RSAES-OAEP、SHA-2 CMSアルゴリズムに関するRFCの参照を追加しました。また、CMS参照に「CMS Multiple Signers Clarification」を追加しました。
Section 1.2: Updated references to ASN.1 to X.680 and BER and DER to X.690.
セクション1.2では、ASN.1の参照先をX.680に、BERおよびDERの参照先をX.690に更新しました。
Section 1.4: Added references to S/MIME MSG 3.1 RFCs.
セクション1.4：S/MIME MSG 3.1 RFCへの参照を追加しました。
Section 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5 made SHOULD-.
セクション2.1（ダイジェストアルゴリズム）：SHA-256をMUST (MUST) として追加し、SHA-1とMD5をSHOULD-に変更しました。
Section 2.2 (signature algorithms): RSA with SHA-256 added as MUST, and DSA with SHA-256 added as SHOULD+, RSA with SHA-1, DSA with SHA-1, and RSA with MD5 changed to SHOULD-, and RSASSA-PSS with SHA-256 added as SHOULD+. Also added note about what S/MIME v3.1 clients support.
セクション2.2（署名アルゴリズム）：RSA with SHA-256をMUST (MUST) として追加し、DSA with SHA-256およびRSASSA-PSS with SHA-256をSHOULD+として追加しました。RSA with SHA-1、DSA with SHA-1、RSA with MD5はSHOULD-に変更しました。また、S/MIME v3.1クライアントの対応状況に関する注記を追加しました。
Section 2.3 (key encryption): DH changed to SHOULD-, and RSAES-OAEP added as SHOULD+. Elaborated requirements for key wrap algorithm.
セクション2.3（鍵暗号化）：DHをSHOULD-に変更し、RSAES-OAEPをSHOULD+として追加しました。鍵ラップアルゴリズムの要件を詳述しました。
Section 2.5.1: Added requirement that receiving agents MUST support both GeneralizedTime and UTCTime.
セクション2.5.1：受信エージェントはGeneralizedTimeとUTCTimeの両方をサポートしなければならない (MUST) という要件を追加しました。
Section 2.5.2: Replaced reference "sha1WithRSAEncryption" with "sha256WithRSAEncryption", "DES-3EDE-CBC" with "AES-128 CBC", and deleted the RC5 example.
セクション2.5.2：「sha1WithRSAEncryption」を「sha256WithRSAEncryption」に、「DES-3EDE-CBC」を「AES-128 CBC」に置き換え、RC5の例を削除しました。
Section 2.5.2.1: Deleted entire section (discussed deprecated RC2).
セクション2.5.2.1：非推奨のRC2を扱っていた節全体を削除しました。
Section 2.7, 2.7.1, Appendix A: references to RC2/40 removed.
セクション2.7、2.7.1、付録A：RC2/40への参照を削除しました。
Section 2.7 (content encryption): AES-128 CBC added as MUST, AES-192 and AES-256 CBC SHOULD+, tripleDES now SHOULD-.
セクション2.7（コンテンツ暗号化）：AES-128 CBCをMUST (MUST) として追加し、AES-192 CBCとAES-256 CBCをSHOULD+に、tripleDESをSHOULD-に変更しました。
Section 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to 2.7.1.1 to 2.7.1.2.
セクション2.7.2.1〜2.7.2.4への参照を、2.7.1.1〜2.7.1.2への参照に更新しました。
Section 3.1.1: Removed text about MIME character sets.
セクション3.1.1：MIMEキャラクターセットに関するテキストを削除しました。
Section 3.2.2 and 3.6: Replaced "encrypted" with "enveloped". Update OID example to use AES-128 CBC oid.
セクション3.2.2および3.6：「encrypted」を「enveloped」に置き換え、OIDの例をAES-128 CBC OIDを使うものに更新しました。
Section 3.4.3.2: Replace micalg parameter for SHA-1 with sha-1.
セクション3.4.3.2：SHA-1用のmicalgパラメーターをsha-1に置き換えました。
Section 4: Updated reference to CERT v3.2.
セクション4：CERT v3.2への参照を更新しました。
Section 4.1: Updated RSA and DSA key size discussion. Moved last four sentences to security considerations. Updated reference to randomness requirements for security.
セクション4.1：RSAおよびDSAの鍵長に関する説明を更新しました。末尾の4文をセキュリティに関する考慮事項へ移し、セキュリティ用乱数の要件に関する参照を更新しました。
Section 5: Added IANA registration templates to update media type registry to point to this document as opposed to RFC 2311.
セクション5：メディアタイプ登録を更新し、RFC 2311ではなくこの文書を参照するためのIANA登録テンプレートを追加しました。
Section 6: Updated security considerations.
セクション6：セキュリティ上の考慮事項を更新しました。
Section 7: Moved references from Appendix B to this section. Updated references. Added informational references to SMIMEv2, SMIMEv3, and SMIMEv3.1.
セクション7：付録Bにあった参考文献をこの節に移し、参照を更新しました。SMIMEv2、SMIMEv3、SMIMEv3.1に関する参考文献も追加しました。
Appendix B: Added Appendix B to move S/MIME v2 to Historic status.
付録B：S/MIME v2をHistoric状態へ移すため、付録Bを追加しました。
CMS allows for a wide variety of options in content, attributes, 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] and [CMS-SHA2] provides additional details regarding the use of the cryptographic algorithms. [ESS] provides additional details regarding the use of additional attributes.
CMSでは、コンテンツ、属性、アルゴリズムのサポートに関して多様な選択肢を利用できます。この節では、すべてのS/MIME実装間で基本的な相互運用性を確保するためのサポート要件と推奨事項を示します。[CMSALG]と[CMS-SHA2]には暗号アルゴリズムの使用に関する詳細が記載され、[ESS]には追加属性の使用に関する詳細が記載されています。
Sending and receiving agents MUST support SHA-256 [CMS-SHA2] and SHOULD- 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-256 [CMS-SHA2]をMUST (MUST) でサポートし、SHA-1 [CMSALG]をSHOULD-でサポートします。受信側エージェントは、MD5ダイジェスト付きS/MIME v2 SignedDataオブジェクトとの後方互換性のため、MD5 [CMSALG]もSHOULD-でサポートします。
Receiving agents:
受信エージェント：
- MUST support RSA with SHA-256.
- SHA-256でRSAをサポートしなければなりません (MUST)。
- SHOULD+ support DSA with SHA-256.
- SHA-256を用いるDSAをSHOULD+レベルでサポートします。
- SHOULD+ support RSASSA-PSS with SHA-256.
- SHA-256を用いるRSASSA-PSSをSHOULD+レベルでサポートします。
- SHOULD- support RSA with SHA-1.
- SHA-1を用いるRSAをSHOULD-レベルでサポートします。
- SHOULD- support DSA with SHA-1.
- SHA-1を用いるDSAをSHOULD-レベルでサポートします。
- SHOULD- support RSA with MD5.
- MD5を用いるRSAをSHOULD-レベルでサポートします。
Sending agents:
送信エージェント：
- MUST support RSA with SHA-256.
- SHA-256でRSAをサポートしなければなりません (MUST)。
- SHOULD+ support DSA with SHA-256.
- SHA-256を用いるDSAをSHOULD+レベルでサポートします。
- SHOULD+ support RSASSA-PSS with SHA-256.
- SHA-256を用いるRSASSA-PSSをSHOULD+レベルでサポートします。
- SHOULD- support RSA with SHA-1 or DSA with SHA-1.
- SHA-1を用いるRSAまたはDSAをSHOULD-レベルでサポートします。
- SHOULD- support RSA with MD5.
- MD5を用いるRSAをSHOULD-レベルでサポートします。
See Section 4.1 for information on key size and algorithm references.
キーサイズとアルゴリズムの参照については、セクション4.1を参照してください。
Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and rsaEncryption and might not implement sha256withRSAEncryption. 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.1クライアントは、id-dsa-with-sha1とrsaEncryptionを使った署名の検証をサポートしますが、sha256withRSAEncryptionは実装していない場合があります。S/MIME v3クライアントは、id-dsa-with-sha1を使った署名または署名検証しか実装していない場合があり、このフィールドのAlgorithmIdentifierにid-dsaを使うこともあります。受信側クライアントはid-dsaをid-dsa-with-sha1と同等のものとして認識すべきです (SHOULD)。送信側クライアントがこのアルゴリズムを使う場合はid-dsa-with-sha1を使わなければなりません (MUST)。また、S/MIME v2クライアントに義務付けられているのは、SHA-1またはMD5を使うrsaEncryptionによるデジタル署名の検証だけです。id-dsa-with-sha1やid-dsaを実装していない場合もあります。
Receiving and sending agents:
エージェントの受信と送信：
- MUST support RSA Encryption, as specified in [CMSALG].
- [cmsalg]で指定されているように、RSA暗号化をサポートしなければなりません (MUST)。
- SHOULD+ support RSAES-OAEP, as specified in [RSAOAEP].
- [RSAOAEP]で規定されるRSAES-OAEPをSHOULD+レベルでサポートします。
- SHOULD- support DH ephemeral-static mode, as specified in [CMSALG] and [SP800-57].
- [CMSALG]および[SP800-57]で規定されるDH ephemeral-staticモードをSHOULD-レベルでサポートします。
When DH ephemeral-static is used, a key wrap algorithm is also specified in the KeyEncryptionAlgorithmIdentifier [CMS]. The underlying encryption functions for the key wrap and content encryption algorithm ([CMSALG] and [CMSAES]) and the key sizes for the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm with AES-128 content encryption algorithm). As AES-128 CBC is the mandatory-to-implement content encryption algorithm, the AES-128 key wrap algorithm MUST also be supported when DH ephemeral-static is used.
DH ephemeral-staticを使う場合、KeyEncryptionAlgorithmIdentifier [CMS]で鍵ラップアルゴリズムも指定します。鍵ラップとコンテンツ暗号化に使う暗号関数（[CMSALG]および[CMSAES]）と、それぞれの鍵長は同じでなければなりません (MUST)（例：AES-128の鍵ラップとAES-128のコンテンツ暗号化）。AES-128 CBCは実装必須のコンテンツ暗号化アルゴリズムであるため、DH ephemeral-staticを使う場合はAES-128の鍵ラップアルゴリズムもサポートしなければなりません (MUST)。
Note that S/MIME v3.1 clients might only implement key encryption and decryption using the rsaEncryption algorithm. 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.1クライアントはrsaEncryptionを使った鍵暗号化と復号だけを実装している場合があります。S/MIME v3クライアントはDiffie-Hellmanを使った鍵暗号化と復号だけを実装している場合があります。また、S/MIME v2クライアントがコンテンツ暗号鍵を復号する際に使えるのはrsaEncryptionだけです。
There are several CMS content types. Of these, only the Data, SignedData, EnvelopedData, and CompressedData content types are currently used for S/MIME.
CMSには複数のコンテンツタイプがあります。そのうち、現在S/MIMEで使われているのはData、SignedData、EnvelopedData、CompressedDataだけです。
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 media type 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 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.
送信側エージェントは、「内側」のMIMEメッセージ内容を識別するために、コンテンツタイプ識別子id-dataを使わなければなりません (MUST)。たとえばMIMEデータにデジタル署名を適用する場合、CMS SignedDataのencapContentInfo内のeContentTypeにid-dataのオブジェクト識別子を含めなければなりません (MUST)。また、メディアタイプはSignedDataのencapContentInfo内のeContent OCTET STRINGに格納しなければなりません (MUST)。ただし、送信側エージェントがmultipart/signedを使う場合は、この文書のセクション3.4.3に従い、eContentは存在しません。別の例として、MIMEデータを暗号化する場合、CMS EnvelopedDataのencryptedContentInfo内のcontentTypeにid-dataのオブジェクト識別子を含めなければなりません (MUST)。暗号化されたMIME内容は、同じencryptedContentInfo内のencryptedContent OCTET STRINGに格納しなければなりません (MUST)。
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コンテンツタイプを使ってメッセージにデジタル署名を適用しなければなりません (MUST)。署名情報がない特殊な場合には、証明書を伝えるためにもSignedDataを使います。メッセージに署名すると、認証、メッセージ完全性、および送信元の否認防止が得られます。
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.
このコンテンツタイプは、メッセージのデータ機密性を確保するために使います。この機能を使う送信者は、宛先となる各受信者の公開鍵にアクセスできる必要があります。
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 the message's size.
このコンテンツタイプは、メッセージを圧縮するために使います。認証、メッセージ完全性、否認防止、データ機密性は提供せず、メッセージサイズの削減だけを目的とします。
See Section 3.6 for further guidance on the use of this type in conjunction with other CMS types.
他のCMSタイプと組み合わせて、このタイプの使用に関するさらなるガイダンスについては、セクション3.6を参照してください。
The SignerInfo type allows the inclusion of unsigned and signed attributes 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つのインスタンスを処理できなければなりません (MUST)。送信エージェントは、各S/MIMEメッセージに次の各署名属性の1つのインスタンスを生成すべきです (SHOULD)。
- Signing Time (section (Section 2.5.1 in this document)
- Signing Time（この文書のセクション2.5.1）
- SMIME Capabilities (section (Section 2.5.2 in this document)
- SMIME Capabilities（この文書のセクション2.5.2）
- Encryption Key Preference (section (Section 2.5.3 in this document)
- Encryption Key Preference（この文書のセクション2.5.3）
- Message Digest (section (Section 11.2 in [CMS])
- Message Digest（[CMS]のセクション11.2）
- Content Type (section (Section 11.1 in [CMS])
- Content Type（[CMS]のセクション11.1）
Further, receiving agents SHOULD be able to handle zero or one instance of the signingCertificate and signingCertificatev2 signed attributes, as defined in Section 5 of RFC 2634 [ESS] and Section 3 of RFC 5035 [ESS].
さらに、受信側エージェントは、RFC 2634のセクション5 [ESS]およびRFC 5035のセクション3 [ESS]で定義される署名付き属性signingCertificateとsigningCertificatev2について、それぞれ0個または1個を適切に処理すべきです (SHOULD)。
Sending agents SHOULD generate one instance of the signingCertificate or signingCertificatev2 signed attribute in each SignerInfo structure.
送信エージェントは、各SignerInfo構造でsigningCertificateまたはsigningCertificatev2の署名属性の1つのインスタンスを生成すべきです (SHOULD)。
Additional attributes and values for these attributes might be defined in the future. Receiving agents SHOULD handle attributes or values that they do 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)。
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.
signing-time属性は、メッセージに署名した時刻を伝えるために使います。署名時刻は通常、メッセージ送信者が生成するため、その信頼性は送信者の信頼性に依存します。
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:
送信側エージェントは、2049年までの署名時刻をUTCTimeで符号化しなければなりません (MUST)。2050年以降の署名時刻はGeneralizedTimeで符号化しなければなりません (MUST)。UTCTimeのCHOICEを使う場合、S/MIMEエージェントは年フィールド（YY）を次のように解釈しなければなりません (MUST)。
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以上なら年を19YYと解釈し、YYが50未満なら年を20YYと解釈します。
Receiving agents MUST be able to process signing-time attributes that are encoded in either UTCTime or GeneralizedTime.
受信エージェントは、UTCTIMEまたはGeneralizedTimeでエンコードされる署名時間属性を処理できなければなりません (MUST)。
The SMIMECapabilities attribute includes signature algorithms (such as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128 CBC"), and key encipherment algorithms (such as "rsaEncryption"). There are also several identifiers that 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属性には、署名アルゴリズム（例：「sha256WithRSAEncryption」）、対称アルゴリズム（例：「AES-128 CBC」）、鍵暗号化アルゴリズム（例：「rsaEncryption」）が含まれます。また、バイナリー符号化や圧縮など、ほかの任意機能への対応を示す識別子も複数含まれます。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 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属性が存在する場合、SignedAttributeでなければならず (MUST)、UnsignedAttributeであってはなりません (MUST NOT)。CMSではSignedAttributesをSET OF Attributeとして定義します。signerInfoのSignedAttributesにSMIMECapabilities属性を複数含めてはなりません (MUST NOT)。CMSでは、AttributeのASN.1構文にattrValues SET OF AttributeValueを含めます。SMIMECapabilities属性に含めるAttributeValueは1つだけでなければなりません (MUST)。attrValues SET OF AttributeValueにAttributeValueが0個または複数含まれていてはなりません (MUST NOT)。
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属性内のオブジェクト識別子（OID）は優先度順に並べますが、署名アルゴリズム、対称アルゴリズム、鍵暗号化アルゴリズムなどのカテゴリごとに論理的に分けるべきです (SHOULD)。
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 AES-128 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属性の構造は、対応する機能を特定するための単純な表検索とバイナリー比較を容易にします。たとえば、AES-128 CBCのSMIMECapabilityは、どの実装でも同一のDER符号化でなければなりません (MUST)。符号化を一致させる必要があるため、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.
各機能に対応するOIDのパラメーターでは、同じアルゴリズムの2つのインスタンスを区別するために必要なパラメーターをすべて指定しなければなりません (MUST)。
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.
アルゴリズムに対応するOIDには、OIDから用途を判別できない場合を除き、そのアルゴリズム自体と同じOIDを使うべきです (SHOULD)。たとえば以前の仕様では、rsaEncryptionが署名アルゴリズムと鍵暗号化アルゴリズムのどちらも表し得たため、用途が曖昧でした。OIDの用途が曖昧な場合は、登録済みSMIMECapabilities一覧の管理者が、そのOIDをどの種類のアルゴリズムに使うか決定します。もう一方の用途には、smimeCapabilities OIDの下に新しいOIDを割り当てなければなりません (MUST)。
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. 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一覧では、パラメーターが必要なOIDについてその値を定めます。特に、鍵長が可変の対称暗号では鍵長を指定します。特定のOIDで区別に使うパラメーターがない場合、パラメーターを省略しなければならず (MUST)、NULLとして符号化してはなりません (MUST NOT)。SMIMECapabilities属性に新しい値が将来定義される場合があります。受信側エージェントは、認識できない値を含むSMIMECapabilitiesオブジェクトも適切に処理しなければなりません (MUST)。
Section 2.7.1 explains a strategy for caching capabilities.
セクション2.7.1では、キャッシュ機能の戦略について説明します。
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.
Encryption Key Preference属性により、署名者は、自分の証明書のうちどれが優先する暗号化鍵を含むかを明確に示せます。この属性は、暗号化と署名に別々の鍵を使うクライアントとの相互運用性を高めるために設計されています。この属性を見る者に対し、列挙された証明書のうち、将来の暗号化メッセージのセッション鍵を暗号化するために使う証明書を示します。
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でなければならず (MUST)、UnsignedAttributeであってはなりません (MUST NOT)。CMSではSignedAttributesをSET OF Attributeとして定義します。signerInfoのSignedAttributesにSMIMEEncryptionKeyPreference属性を複数含めてはなりません (MUST NOT)。CMSでは、AttributeのASN.1構文にattrValues SET OF AttributeValueを含めます。SMIMEEncryptionKeyPreference属性に含めるAttributeValueは1つだけでなければなりません (MUST)。attrValues SET OF AttributeValueにAttributeValueが0個または複数含まれていてはなりません (MUST NOT)。
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 certificate is not the same as the certificate used to sign the message.
この属性を使用する場合、送信エージェントは、署名されたメッセージに含まれる証明書の集合に、参照される証明書を含めるべきです (SHOULD)。その証明書が以前に受信エージェントに提供されている場合は、省略してもよいです (MAY)。一般的に使用される、または優先される暗号化証明書がメッセージの署名に使用した証明書と同じでない場合、送信エージェントはこの属性を使用すべきです (SHOULD)。
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では、優先設定情報を保存する方法を説明しています。
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エンベロープデータメッセージを送信する際に使用する主要な管理証明書を決定するには、次の手順に従うべきです (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 signer of a X.509 certificate that can be used for key management.
- SMIMEEncryptionKeyPreference属性が目的の受信者から受け取ったSignedDataオブジェクトに含まれていない場合、鍵管理に使えるX.509証明書の署名者と同じsubject nameを持つX.509証明書がないか、X.509証明書の集合を検索すべきです (SHOULD)。
- 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エージェントはいずれかを任意に選べます。
S/MIME v3.2 implementations MUST support both issuerAndSerialNumber and subjectKeyIdentifier. Messages that use the subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
S/MIME v3.2の実装は、issuerAndSerialNumberとsubjectKeyIdentifierの両方をサポートしなければなりません (MUST)。subjectKeyIdentifierを使うメッセージはS/MIME v2クライアントでは読み取れません。
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 matching certificate during signature verification before indicating an error condition.
subjectKeyIdentifierに、証明書を一意に識別するには適さない値を使う証明書もある点に注意してください。実装は、異なる主体の複数の証明書で同じsubjectKeyIdentifier値が使われる場合に備えなければなりません (MUST)。また、エラーを示す前に、署名検証時に一致する証明書を一つずつ試さなければなりません (MUST)。
Sending and receiving agents:
エージェントの送信と受信：
- MUST support encryption and decryption with AES-128 CBC [CMSAES].
- AES-128 CBC [CMSAES]で暗号化と復号化をサポートしなければなりません (MUST)。
- SHOULD+ support encryption and decryption with AES-192 CBC and AES-256 CBC [CMSAES].
- AES-192 CBCおよびAES-256 CBCでの暗号化と復号をSHOULD+レベルでサポートします。
- SHOULD- support encryption and decryption with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG].
- DES EDE3 CBC（以下、tripleDES）での暗号化と復号をSHOULD-レベルでサポートします [CMSALG]。
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)。妥当なクロックずれを大幅に超えるほど未来の署名時刻や、署名を検証できなかったメッセージの機能一覧を受け入れてはなりません (MUST NOT)。
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 message. If the sending agent decides that weak encryption is unacceptable for this data, then the sending agent MUST NOT use a weak algorithm. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use.
メッセージを送信する前に、送信エージェントは、メッセージ内の特定のデータに弱い暗号化を使用する意思があるかどうかを決定しなければなりません (MUST)。送信エージェントがこのデータに対して弱い暗号化が受け入れられないと判断した場合、送信エージェントは弱いアルゴリズムを使用してはなりません (MUST NOT)。弱い暗号化を使用または使用しないという決定は、このセクションで使用する暗号化アルゴリズムについて他の決定を上書きします。
Sections 2.7.1.1 through 2.7.1.2 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.1.1〜2.7.1.2では、メッセージに適用する暗号方式を決める際に送信側エージェントが使うべき判断基準を説明します (SHOULD)。基準には順序があるため、送信側エージェントは記載された順に判断すべきです (SHOULD)。
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.
送信エージェントが、これから暗号化しようとしているメッセージの受信者から機能の集合を受け取っている場合、送信エージェントは、リスト内で送信エージェントが暗号化の方法を知っている最初の機能（つまり、想定される受信者が最も優先する機能）を選択することによって、その情報を使用すべきです (SHOULD)。送信エージェントは、受信者がメッセージを復号できると合理的に期待できる場合は、リスト内の機能のいずれかを使用すべきです (SHOULD)。
If the following two conditions are met:
次の2つの条件が満たされている場合：
- 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,
- 送信エージェントには、受信者のS/MIMEのバージョンに関する知識がありません。
then the sending agent SHOULD use AES-128 because it is a stronger algorithm and is required by S/MIME v3.2. If the sending agent chooses not to use AES-128 in this step, it SHOULD use tripleDES.
その場合、AES-128はより強力なアルゴリズムであり、S/MIME v3.2で必須とされているため、送信エージェントはAES-128を使用すべきです (SHOULD)。このステップで送信エージェントがAES-128を使用しないことを選択した場合は、tripleDESを使用すべきです (SHOULD)。
All algorithms that use 40-bit keys are 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 a weak encryption algorithm before sending the data, and possibly allow the human to use a stronger encryption method such as tripleDES or AES.
40ビット鍵を使うアルゴリズムは、多くの人から弱い暗号と見なされています。人が操作する送信側エージェントは、弱い暗号を使ってデータを送信するリスクを送信前に利用者が判断できるようにし、必要に応じてtripleDESやAESなどのより強い暗号方式を利用できるようにすべきです (SHOULD)。
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 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.
受信者グループ内で共通して使える暗号機能がない場合、送信側エージェントは複数のメッセージを送信せざるを得ません。強いアルゴリズムで暗号化したメッセージに続けて、同じメッセージを弱いアルゴリズムでも送信すると、通信路を監視する者は弱い方を復号するだけで、強く暗号化されたメッセージの内容も知ることができます。
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 media 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 that 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コンテンツタイプを組み合わせて構成し、複数のメディアタイプとCMSコンテンツタイプを使います。保護対象データは常に正準化されたMIMEエンティティです。MIMEエンティティや証明書、アルゴリズム識別子などをCMS処理機構に渡すと、CMSオブジェクトが生成されます。最後に、そのCMSオブジェクトをMIMEで包みます。Enhanced Security Services for S/MIME [ESS]では、入れ子になった保護付きS/MIMEメッセージの形式を説明しています。また、multipart/signedとapplication/pkcs7-mimeを署名に使う三重にカプセル化されたS/MIMEメッセージの形式も説明しています。
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では、エンベロープのみ、署名のみ、署名とエンベロープを組み合わせたMIME形式をそれぞれ複数定義しています。特に署名付きメッセージでは、さまざまな環境に対応するため複数の形式が必要です。どの形式を選ぶかの基準も説明します。
The reader of this section is expected to understand MIME as described in [MIME-SPEC] and [MIME-SECURE].
この節の読者は、[MIME-SPEC]および[MIME-SECURE]で説明される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 message headers and MIME body, and does not include the RFC-822 header. 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 header is required, the use of the message/rfc822 media type is explained later in this section.
S/MIMEはMIMEエンティティを保護するために使います。MIMEエンティティは、メッセージの一部、複数の部分、またはすべての部分を含むメッセージ全体の場合があります。メッセージ全体を表すMIMEエンティティにはMIMEメッセージヘッダーとMIMEボディだけが含まれ、RFC-822ヘッダーは含まれません。S/MIMEは、インターネットメール以外のアプリケーションで使われるMIMEエンティティも保護できます。RFC-822ヘッダーを保護する必要がある場合にmessage/rfc822メディアタイプを使う方法は、この節の後半で説明します。
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 Sections 3.2, 3.4, and elsewhere.
この節で保護対象として説明するMIMEエンティティは、「内側」のMIMEエンティティと考えられます。より大きなMIMEメッセージの中で最も内側にあるオブジェクトです。「外側」のMIMEエンティティをCMSコンテンツタイプに処理する方法は、セクション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 when signing. The description of the procedures from [MIME-SPEC] is repeated here, but it is suggested that the reader refer to that document for the exact procedure. This section also describes additional requirements.
MIMEエンティティの準備手順は[MIME-SPEC]に記載されています。ここでも同じ手順を使いますが、署名時には追加の制約があります。[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エンティティは、共通の手順で作成します。特にmultipart/signed形式によるクリア署名では、メール転送中に生じる既知の破損を防ぐため、追加手順が推奨されます。変更せずにあらゆる環境へ転送できるよう、エンベロープ化したメッセージや、署名とエンベロープ化を組み合わせたメッセージにもこれらの手順を適用することが推奨されます。
These steps are descriptive rather than prescriptive. The implementer is free to use any procedure as long as the result is the same.
これらの手順は、規範的ではなく説明的です。実装者は、結果が同じである限り、あらゆる手順を自由に使用できます。
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 header fields (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 header fields. It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header.
コンテンツに関係しない外側のメッセージヘッダーフィールド（例：「Subject」、「To」、「From」、「Cc」）を保護するため、送信側クライアントは、完全なMIMEメッセージをmessage/rfc822ラッパーに入れ、これらのヘッダーフィールドにS/MIMEセキュリティ機能を適用してもかまいません (MAY)。保護されていない「外側」のヘッダーとともに「内側」のヘッダーをどう表示するかは、受信側クライアントが決めます。
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エンティティのContent-Typeがmessage/rfc822なら、ヘッダーを保護する意図があったとみなせます。このエンティティは、前述したヘッダー統合の問題を考慮したうえで、最上位メッセージとして表示すべきです (SHOULD)。
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エンティティは、署名の作成環境と検証環境の双方で一意かつ明確に表現できる正準形式に変換しなければなりません (MUST)。MIMEエンティティは署名だけでなく、エンベロープ化や圧縮の前にも正準化しなければなりません (MUST)。
The exact details of canonicalization depend on the actual media type and subtype of an entity, and are not described here. Instead, the standard for the particular media 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 that 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.
正準化の詳細はエンティティのメディアタイプとサブタイプによって異なるため、ここでは説明しません。代わりに、該当するメディアタイプの標準を参照すべきです (SHOULD)。たとえば、text/plainの正準化はaudio/basicの正準化とは異なります。textタイプ以外の大半は、計算環境によらず表現が1つだけであり、それを正準表現とみなせます。一般に、正準化は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].
最も一般的で重要な正規化はテキストに対するものであり、テキストは環境によって異なる方法で表現されることがよくあります。主タイプ「text」のMIMEエンティティは、行末と文字セットの両方が正規化されていなければなりません (MUST)。行末は文字の組<CR><LF>でなければならず (MUST)、charsetは登録済みのcharset [CHARSETS]であるべきです (SHOULD)。正規化の詳細は[MIME-SPEC]で規定されています。
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など、一部のcharsetでは同じ文字に複数の表現があります。そのようなテキストに署名する場合は、そのcharsetで指定されている正準表現を使わなければなりません (MUST)。
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 field is present, the transfer encoding is presumed to be 7BIT.
multipart/signed形式で署名する場合を除き、以下の保護対象MIMEエンティティを生成する際に転送エンコーディングは必須ではありません。S/MIME実装はバイナリーMIMEオブジェクトを処理できなければなりません (MUST)。Content-Transfer-Encodingヘッダーフィールドがない場合、転送エンコーディングは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 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.
ただし、S/MIME実装は、保護するすべてのMIMEエンティティに対してセクション3.1.3で説明する転送エンコーディングを使うべきです (SHOULD)。転送にさらされないエンベロープ化データも含めて7ビットMIMEエンティティだけを保護するのは、内容を変更せずにどの環境でも扱えるようにするためです。たとえば、信頼できるゲートウェイがメッセージからエンベロープだけを取り除き、署名は残したまま、受信者が署名を直接検証できるよう転送する場合があります。サイト内の転送経路が8ビット透過でない場合（メールゲートウェイが1台だけの広域網など）、元のMIMEエンティティが7ビットデータだけでなければ署名を検証できません。
S/MIME implementations that "know" that all intended recipients 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.
意図したすべての受信者が内側（最外部以外）のバイナリーMIMEオブジェクトを処理できると「把握している」S/MIME実装は、内側のエンティティに対して7ビット安全な転送エンコーディングではなくバイナリーエンコーディングを使うべきです (SHOULD)。base64などの7ビット安全な符号化では、メッセージサイズが不必要に大きくなります。実装は、id-cap-preferBinaryInside SMIMECapabilities属性の解釈、事前の合意、その他の方法によって、受信側の実装が内側のバイナリーMIMEエンティティを処理できると「把握」してもかまいません (MAY)。
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人以上の意図された受信者が内側のバイナリMIMEオブジェクトを処理できない場合、または意図した受信者のいずれかでこの機能が不明な場合、S/MIME実装は、保護するすべてのMIMEエンティティについてセクション3.1.3で説明されている転送エンコードを使用すべきです (SHOULD)。
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.
multipart/signedエンティティを標準的なインターネットSMTP基盤など7ビットテキストに制約されたトランスポートで送信する可能性がある場合、7ビットテキストとして表現できるよう転送エンコーディングを適用しなければなりません (MUST)。すでに7ビットデータであるMIMEエンティティには転送エンコーディングは不要です。8ビットテキストやバイナリーデータなどのエンティティは、quoted-printableまたはbase64で符号化できます。
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 cannot 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.
- とにかくエージェントはデータを送信することができます。これにより、8番目のビットが破損する可能性が最も高くなります。これも署名を無効にします。
- The agent could return the message to the sender.
- エージェントはメッセージを送信者に返すことができます。
[MIME-SECURE] prohibits an agent from changing the transfer encoding of the first part of a multipart/signed message. If a compliant agent that cannot 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]では、multipart/signedメッセージの最初の部分の転送エンコーディングをエージェントが変更することを禁止しています。8ビットやバイナリーデータを転送できない準拠エージェントが、最初の部分にそのデータを含むmultipart/signedメッセージを受け取った場合、そのメッセージを配信不能として送信者に返送せざるを得ません。
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 the transfer encoded parts, all MUST be <CR><LF>.
この例は、転送エンコーディングを施したmultipart/mixedメッセージを示します。このメッセージにはテキスト部分と添付ファイルが含まれます。サンプルの本文にはUS-ASCII以外の文字が含まれるため、転送エンコーディングが必要です。表示は省略していますが、各行の末尾は<CR><LF>です。MIMEヘッダー、本文、転送エンコードされた部分の行末はすべて<CR><LF>でなければなりません (MUST)。
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
=A1Hola Michael!
How do you like the new S/MIME specification?
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.
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
--bar
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI=
--bar--
The application/pkcs7-mime media type is used to carry CMS content types including EnvelopedData, SignedData, and CompressedData. The details of constructing these entities are described in subsequent sections. This section describes the general characteristics of the application/pkcs7-mime media type.
application/pkcs7-mimeメディアタイプは、EnvelopedData、SignedData、CompressedDataなどのCMSコンテンツタイプを運びます。これらのエンティティの構築方法は後続の節で説明します。この節ではapplication/pkcs7-mimeメディアタイプの一般的な特徴を説明します。
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.
eContentTypeがid-dataの場合、運ばれるCMSオブジェクトには、セクション3.1の手順で準備したMIMEエンティティが必ず含まれます。eContentTypeが別の値を持つ場合は、ほかの内容を含めてもかまいません (MAY)。署名付き受領通知の例は[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 media type.
CMSコンテンツタイプはバイナリデータであるため、ほとんどの場合、SMTP輸送で使用する場合、ベース64転送エンコードが適切です。使用される転送エンコーディングは、オブジェクトを送信するトランスポートに依存し、メディアタイプの特性ではありません。
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エンティティの転送エンコーディングを指します。セクション3.1で説明する、CMSオブジェクトによって保護される「内側」のMIMEエンティティの転送エンコーディングとは完全に別のもので、関連もありません。
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 Content-Type header field of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections.
application/pkcs7-mimeオブジェクトには複数の種類があります。そのため送信側エージェントは、受信側エージェントにASN.1のデコードを強いることなく内容を把握できるよう、できる限りの情報を提供すべきです (SHOULD)。すべてのapplication/pkcs7-mimeオブジェクトのContent-Typeヘッダーフィールドには、後続の節で説明する任意のsmime-typeパラメーターを含めるべきです (SHOULD)。
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:
application/pkcs7-mimeでは、古いシステムとの互換性のため、送信側エージェントはContent-Typeフィールドに任意のnameパラメーターを出力すべきです (SHOULD)。また、送信側エージェントはfilenameパラメーター付きの任意のContent-Dispositionフィールド[CONTDISP]も出力すべきです (SHOULD)。これらのパラメーターを出力する場合、その値は適切な拡張子を持つファイル名であるべきです (SHOULD)。
Media Type File Extension
application/pkcs7-mime (SignedData, EnvelopedData) .p7m
application/pkcs7-mime (degenerate SignedData .p7c
certificate management message)
application/pkcs7-mime (CompressedData) .p7z
application/pkcs7-signature (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文字のベース名と、それに続く3文字の拡張子に制限すべきです (SHOULD)。8文字のベース名には任意の一意な名前を使えます。MIMEエンティティがS/MIMEに関係することを示すには、ベース名smimeを使うべきです (SHOULD)。
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 media 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 media types and MUST NOT rely on the file extensions.
ファイル名には2つの役割があります。S/MIMEオブジェクトをディスク上のファイルとして扱いやすくすることと、ゲートウェイを越えてタイプ情報を伝えることです。たとえば、S/MIMEを特別に認識しないゲートウェイにapplication/pkcs7-mimeのMIMEエンティティが届くと、ゲートウェイはメディアタイプをapplication/octet-streamに設定して一般的な添付ファイルとして扱い、タイプ情報を失うことがあります。一方、添付ファイル名はゲートウェイを越えて保持されることが多く、受信側は適切なアプリケーション（この場合は独立したS/MIME処理アプリケーション）を選べます。この仕組みは特定の環境で実装を補助する便宜機能です。適切なS/MIME実装はメディアタイプを使わなければならず (MUST)、ファイル拡張子に依存してはなりません (MUST NOT)。
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.
application/pkcs7-mimeコンテンツタイプでは、任意のsmime-typeパラメーターを定義しています。このパラメーターは、含まれるコンテンツの情報とともに、適用したセキュリティ（署名またはエンベロープ化）の詳細を伝えるためのものです。この仕様では、次のsmime-typeを定義します。
Name CMS Type Inner Content
enveloped-data EnvelopedData id-data
signed-data SignedData id-data
certs-only SignedData none
compressed-data CompressedData id-data
In order for consistency to be obtained with future specifications, the following guidelines SHOULD be followed when assigning a new smime-type parameter.
将来の仕様との一貫性を保つため、新しいsmime-typeパラメーターを割り当てる場合は、次の指針に従うべきです (SHOULD)。
1. If both signing and encryption can be applied to the content, then two values for smime-type SHOULD be assigned "signed-*" and "enveloped-*". If one operation can be assigned, then this can be omitted. Thus, since "certs-only" can only be signed, "signed-" is omitted.
1. コンテンツに署名と暗号化の両方を適用できる場合、smime-typeにはsigned-*とenveloped-*の2つの値を割り当てるべきです (SHOULD)。一方の処理しか適用できない場合、その接頭辞は省略できます。たとえばcerts-onlyでは署名しかできないため、signed-は省略されています。
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. コンテンツOIDには共通の文字列を割り当てるべきです (SHOULD)。MIMEが内側のコンテンツである場合、id-dataコンテンツOIDにはdataを使います。
3. If no common string is assigned, then the common string of "OID.<oid>" is recommended (for example, "OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC).
3. 共通の文字列を割り当てない場合は、OID.<oid>という形式を推奨します（例：OID.2.16.840.1.101.3.4.1.2はAES-128 CBCを表します）。
It is explicitly intended that this field be a suitable hint for mail client applications to indicate whether a message is "signed" or "enveloped" without having to tunnel into the CMS payload.
このフィールドは、CMSペイロードの内部を解析しなくてもメッセージが署名済みかエンベロープ化済みかを判別できるよう、メールクライアントに適切なヒントを与えることを明確に意図しています。
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. エンベロープ化するMIMEエンティティをセクション3.1に従って準備します。
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オブジェクトに処理します。各受信者向けにコンテンツ暗号鍵のコピーを暗号化することに加え、送信元向けのコピーも暗号化してEnvelopedDataに含めるべきです (SHOULD)（[CMS]のセクション6を参照）。
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オブジェクトをapplication/pkcs7-mimeのMIMEエンティティに入れます。
The smime-type parameter for enveloped-only messages is "enveloped-data". The file extension for this type of message is ".p7m".
エンベロープのみのメッセージのsmime-typeパラメーターはenveloped-dataです。この種類のメッセージのファイル拡張子は.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
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V
There are two formats for signed messages defined for S/MIME:
S/MIME用に定義された署名されたメッセージの2つの形式があります。
- application/pkcs7-mime with SignedData.
- SignedDataを使用したapplication/pkcs7-mime。
- multipart/signed.
- multipart/signed。
In general, the multipart/signed form is preferred for sending, and receiving agents MUST be able to handle both.
一般に、送信にはmultipart/signed形式が好まれ、受信エージェントは両方を処理できなければなりません (MUST)。
There are no hard-and-fast rules as to when a particular signed-only format is chosen. 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 or not they have S/MIME software. 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.
multipart/signed形式を使用して署名されたメッセージは、受信者がS/MIMEソフトウェアを持っているかどうかにかかわらず、常に閲覧できます。また、MIMEネイティブのユーザーエージェントを使用している場合でも、ゲートウェイによって変換されたメッセージである場合でも閲覧できます。この文脈で「閲覧できる」とは、メッセージが持ちうる他のMIME構造も含め、署名されたメッセージではないかのように、本質的にメッセージを処理できることを意味します。
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 that would break the signature.
SignedData形式で署名されたメッセージは、受信者にS/MIME機能がなければ閲覧できません。一方、SignedData形式は、悪意のない中継エージェントによるメッセージ内容の変更を防ぎます。そのようなエージェントが行う行折り返しやContent-Transfer-Encodingの変更でも、署名が壊れる可能性があります。
This signing format uses the application/pkcs7-mime media type. The steps to create this format are:
この署名形式では、application/pkcs7-mimeメディアタイプを使用します。この形式を作成する手順は次のとおりです。
Step 1. The MIME entity is prepared according to Section 3.1.
ステップ1. MIMEエンティティは、セクション3.1に従って準備されています。
Step 2. The MIME entity and other required data are 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オブジェクトをapplication/pkcs7-mimeの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を使うapplication/pkcs7-mimeメッセージのsmime-typeパラメーターはsigned-dataです。この種類のメッセージのファイル拡張子は.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
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75
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 media type described in [MIME-SECURE]. The multipart/signed media 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]で説明されるmultipart/signedメディアタイプを使い、2つの部分で構成します。第1部分には署名対象のMIMEエンティティが含まれ、第2部分にはdetached signatureであるCMS SignedDataオブジェクトが含まれます。このオブジェクトではencapContentInfoのeContentフィールドが存在しません。
This media 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.
このメディアタイプには、SignedData型のCMSオブジェクトを1つ含むCMS ContentInfoが必ず含まれます。SignedDataのencapContentInfo内のeContentフィールドは存在してはなりません (MUST)。signerInfosフィールドにはMIMEエンティティへの署名が含まれます。
The file extension for signed-only messages using application/pkcs7- signature is ".p7s".
application/pkcs7-signatureを使う署名のみのメッセージのファイル拡張子は.p7sです。
Step 1. The MIME entity to be signed is prepared according to Section 3.1, taking special care for clear-signing.
ステップ1. 署名するMIMEエンティティを、クリア署名に特に注意してセクション3.1に従い準備します。
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. encapContentInfoのeContentフィールドが存在しないSignedDataオブジェクトを得るため、MIMEエンティティを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. MIMEエンティティは、セクション3.1で説明されている以外の処理を行わずに、multipart/signedメッセージの最初の部分に挿入されます。
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オブジェクトに転送エンコーディングが適用され、それがタイプapplication/pkcs7-signatureのMIMEエンティティに挿入されます。
Step 5. The MIME entity of the application/pkcs7-signature is inserted into the second part of the multipart/signed entity.
ステップ5. application/pkcs7-signatureのMIMEエンティティが、multipart/signedエンティティの2番目の部分に挿入されます。
The multipart/signed Content-Type has two required parameters: the protocol parameter and the micalg parameter.
multipart/signedのContent-Typeには、protocolパラメーターとmicalgパラメーターの2つが必須です。
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.
protocolパラメーターはapplication/pkcs7-signatureでなければなりません (MUST)。MIMEではパラメーター値中の「/」を引用符で囲む必要があるため、protocolパラメーターの値は引用符で囲まなければなりません (MUST)。
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パラメーターは、署名の検証時にワンパス処理を可能にします。その値は、Message Integrity Checkの計算に使ったメッセージダイジェストアルゴリズムによって決まります。複数のダイジェストアルゴリズムを使う場合は、[MIME-SECURE]に従ってカンマで区切らなければなりません (MUST)。micalgパラメーターには、次に示す値を使うべきです (SHOULD)。
Algorithm Value Used
使用されるアルゴリズム値
MD5 md5
SHA-1 sha-1
SHA-224 sha-224
SHA-256 sha-256
SHA-384 sha-384
SHA-512 sha-512
Any other (defined separately in algorithm profile or "unknown"
if not defined)
(Historical note: some early implementations of S/MIME emitted and expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.) Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize. Future names for this parameter will be consistent with the IANA "Hash Function Textual Names" registry.
（歴史的な注記：S/MIMEの初期の実装の一部は、micalgパラメーターに「rsa-md5」、「rsa-sha1」、および「sha1」を出力し、またそれを期待していました。）受信エージェントは、認識できないmicalgパラメーター値から適切に回復できるべきです (SHOULD)。このパラメーターの将来の名前は、IANAの「Hash Function Textual Names」レジストリと整合したものになります。
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
--boundary42
Content-Type: text/plain
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
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
--boundary42--
The content that is digested (the first part of the multipart/signed) consists of 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
This section describes the format for compressing a MIME entity. Please note that versions of S/MIME prior to version 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エンティティを圧縮する形式を説明します。S/MIME 3.1より前のバージョンではCompressedDataの使用が定義されていないため、認識できないことに注意してください。CompressedDataを受信できる能力を示す方法は[CMSCOMPR]で説明されており、互換性を保つうえで推奨される方法です。
Step 1. The MIME entity to be compressed is prepared according to Section 3.1.
ステップ1.圧縮されるMIMEエンティティは、セクション3.1に従って準備されています。
Step 2. The MIME entity and other required data are 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オブジェクトをapplication/pkcs7-mimeのMIMEエンティティに入れます。
The smime-type parameter for compressed-only messages is "compressed-data". The file extension for this type of message is ".p7z".
圧縮のみのメッセージのsmime-typeパラメーターはcompressed-dataです。この種類のメッセージのファイル拡張子は.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
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V
The signed-only, enveloped-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を受信して処理できなければなりません (MUST)。
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 where automatic signature verification is desired, as no private key material is required to verify a signature.
署名、暗号化、圧縮は任意の順序で適用できます。順序は実装者と利用者が選べます。先に署名してからエンベロープ化すると、署名者情報は安全に隠されます。先にエンベロープ化すると署名者情報は露出しますが、エンベロープを開かずに署名を検証できます。署名検証に秘密鍵素材が不要なため、自動的に署名を検証したい環境ではこの順序が役立つ場合があります。
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.
署名と暗号化のどちらを先に行うかには、セキュリティ上の影響があります。暗号化してから署名したメッセージでは、受信者は暗号化ブロックが改変されていないことを検証できますが、署名者とメッセージの平文内容との関係は確認できません。署名してから暗号化したメッセージでは、受信者は署名対象のメッセージ自体が改変されていないと判断できますが、注意深い攻撃者が暗号化メッセージの認証されていない部分を改変している可能性があります。
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.
- バイナリー符号化された暗号化データを圧縮しても大きな効果は得られないため、圧縮は推奨されません。一方、base64で符号化された暗号化データなら、圧縮の効果が期待できます。
- If a lossy compression algorithm is used with signing, you will need to compress first, then sign.
- 署名時に損失のある圧縮アルゴリズムが使用されている場合は、最初に圧縮してから署名する必要があります。
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エンティティは、登録要求への応答などで、証明書やCertificate Revocation Listを転送するために使います。
Step 1. The certificates and/or Certificate Revocation Lists are made available to the CMS generating process that creates a CMS object of type SignedData. The SignedData encapContentInfo eContent field MUST be absent and signerInfos field MUST be empty.
ステップ1. 証明書やCertificate Revocation ListをSignedData型CMSオブジェクトの生成処理に渡します。SignedDataのencapContentInfo内のeContentフィールドは存在してはならず (MUST)、signerInfosフィールドは空でなければなりません (MUST)。
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オブジェクトは、application/pkcs7-mime MIMEエンティティに囲まれています。
The smime-type parameter for a certificate management message is "certs-only". The file extension for this type of message is ".p7c".
証明書管理メッセージのsmime-typeパラメーターはcerts-onlyです。この種類のメッセージのファイル拡張子は.p7cです。
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 certification authority, through a hardware token or diskette, and so on.
メッセージに署名する送信エージェントは、受信エージェントが署名を検証できるように、署名用の証明書を持たなければなりません (MUST)。証明書を取得する方法は、認証局とのやり取り、ハードウェアトークンやディスケットなど、数多くあります。
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.2 does not require a particular certificate request mechanism.
S/MIME v2 [SMIMEv2]では、application/pkcs10ボディパートを使って公開鍵を認証局に「登録」する方法が定められていました。その後、IETF PKIXワーキンググループは証明書要求の別の方法を開発しました。ただし、S/MIME v3.2は特定の証明書要求方式を必須としていません。
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環境での相互運用を考慮しているため、タイプ情報を運ぶためにいくつかの異なるメカニズムが採用されており、S/MIMEメッセージを識別することが少し難しくなります。次の表には、メッセージがS/MIMEメッセージであるかどうかを判断するための基準を示します。メッセージは、以下にリストされている基準のいずれかに一致する場合、S/MIMEメッセージと見なされます。
The file suffix in the table below comes from the "name" parameter in the Content-Type header field, or the "filename" parameter on the Content-Disposition header field. These parameters that give the file suffix are not listed below as part of the parameter section.
以下の表のファイル拡張子は、Content-Typeヘッダーフィールドのnameパラメーター、またはContent-Dispositionヘッダーフィールドのfilenameパラメーターから得られます。これらの拡張子を指定するパラメーターは、表のパラメーター欄には含めていません。
Media type: application/pkcs7-mime parameters: any file suffix: any
Media type: multipart/signed
parameters: protocol="application/pkcs7-signature"
file suffix: any
Media type: application/octet-stream parameters: any file suffix: p7m, p7s, p7c, p7z
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 [CERT32].
受信側エージェントは、デジタルエンベロープの受信者の証明書を取得できるよう、何らかの証明書取得機構を提供しなければなりません (MUST)。この仕様では、S/MIMEエージェントが証明書をどう扱うかではなく、証明書を検証または拒否した後に何をするかだけを扱います。S/MIME証明書に関する問題は[CERT32]で扱います。
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)。
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]から生成しなければならず (MUST)、秘密鍵は安全な方法で保護しなければなりません (MUST)。
An S/MIME user agent MUST NOT generate asymmetric keys less than 512 bits for use with the RSA or DSA signature algorithms.
S/MIMEユーザーエージェントは、RSAまたはDSA署名アルゴリズムで使用するために512ビット未満の非対称キーを生成してはなりません (MUST NOT)。
For 512-bit RSA with SHA-1 see [CMSALG] and [FIPS186-2] without Change Notice 1, for 512-bit RSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] without Change Notice 1, and for 1024-bit through 2048-bit RSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] with Change Notice 1. The first reference provides the signature algorithm's object identifier, and the second provides the signature algorithm's definition.
SHA-1を使う512ビットRSAについては、変更通知1を含まない[CMSALG]および[FIPS186-2]を参照してください。SHA-256を使う512ビットRSAについては、変更通知1を含まない[CMS-SHA2]および[FIPS186-2]を参照してください。SHA-256を使う1024〜2048ビットRSAについては、変更通知1を含む[CMS-SHA2]および[FIPS186-2]を参照してください。最初の参照先は署名アルゴリズムのOIDを、2つ目はその定義を示します。
For 512-bit DSA with SHA-1 see [CMSALG] and [FIPS186-2] without Change Notice 1, for 512-bit DSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see [CMSALG] and [FIPS186-2] with Change Notice 1, for 1024-bit and above DSA with SHA-256 see [CMS-SHA2] and [FIPS186-3]. The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition.
SHA-1を使う512ビットDSAについては、変更通知1を含まない[CMSALG]および[FIPS186-2]を参照してください。SHA-256を使う512ビットDSAについては、変更通知1を含まない[CMS-SHA2]および[FIPS186-2]を参照してください。SHA-1を使う1024ビットDSAについては、変更通知1を含む[CMSALG]および[FIPS186-2]を参照してください。SHA-256を使う1024ビット以上のDSAについては[CMS-SHA2]および[FIPS186-3]を参照してください。最初の参照先は署名アルゴリズムのOIDを、2つ目はその定義を示します。
For RSASSA-PSS with SHA-256, see [RSAPSS]. For 1024-bit DH, see [CMSALG]. For 1024-bit and larger DH, see [SP800-56A]; regardless, use the KDF, which is from X9.42, specified in [CMSALG]. For RSAES-OAEP, see [RSAOAEP].
SHA-256を使うRSASSA-PSSについては[RSAPSS]を参照してください。1024ビットDHについては[CMSALG]を参照してください。1024ビット以上のDHについては[SP800-56A]を参照してください。いずれの場合も、[CMSALG]で規定されるX9.42由来のKDFを使います。RSAES-OAEPについては[RSAOAEP]を参照してください。
The following are the requirements for an S/MIME agent generated RSA, RSASSA-PSS, and DSA signatures:
以下は、RSA、RSASSA-PSS、およびDSA署名を生成したS/MIMEエージェントの要件です。
key size <= 1023 : SHOULD NOT (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for S/MIME receiving agents during signature verification of RSA, RSASSA-PSS, and DSA signatures:
以下は、RSA、RSASSA-PSS、およびDSA署名の署名検証中のS/MIME受信エージェントの要件です。
key size <= 1023 : MAY (see Security Considerations)
1024 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent when establishing keys for content encryption using the RSA, RSA-OAEP, and DH algorithms:
RSA、RSA-OAEP、およびDHアルゴリズムを使用してコンテンツ暗号化のキーを確立する際のS/MIMEエージェントの要件は次のとおりです。
key size <= 1023 : SHOULD NOT (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent when establishing keys for content decryption using the RSA, RSAES-OAEP, and DH algorithms:
RSA、RSAES-OAEP、およびDHアルゴリズムを使用してコンテンツ復号化のキーを確立する際のS/MIMEエージェントの要件は次のとおりです。
key size <= 1023 : MAY (see Security Considerations)
1024 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following information updates the media type registration for application/pkcs7-mime and application/pkcs7-signature to refer to this document as opposed to RFC 2311.
以下の情報は、application/pkcs7-mimeおよびapplication/pkcs7-signatureのメディアタイプ登録を更新し、RFC 2311ではなくこの文書を参照するものです。
Note that other documents can define additional MIME media types for S/MIME.
他のドキュメントでは、S/MIME用の追加のMIMEメディアタイプを定義できることに注意してください。
Type name: application
タイプ名：application
Subtype Name: pkcs7-mime
サブタイプ名：pkcs7-mime
Required Parameters: NONE Optional Parameters: smime-type/signed-data smime-type/enveloped-data smime-type/compressed-data smime-type/certs-only name
必須パラメーター：NONE。任意パラメーター：smime-type/signed-data、smime-type/enveloped-data、smime-type/compressed-data、smime-type/certs-only、name
Encoding Considerations: See Section 3 of this document
考慮事項のエンコード：このドキュメントのセクション3を参照してください
Security Considerations: See Section 6 of this document
セキュリティ上の考慮事項：このドキュメントのセクション6を参照してください
Interoperability Considerations: See Sections 1-6 of this document
相互運用性の考慮事項：このドキュメントのセクション1〜6を参照してください
Published Specification: RFC 2311, RFC 2633, and this document
公開された仕様：RFC 2311、RFC 2633、およびこのドキュメント
Applications that use this media type: Security applications
このメディアタイプを使用するアプリケーション：セキュリティアプリケーション
Additional information: NONE
追加情報：なし
Person & email to contact for further information: S/MIME working group chairs smime-chairs@tools.ietf.org
詳細問い合わせ先：S/MIMEワーキンググループ議長、smime-chairs@tools.ietf.org
Intended usage: COMMON
用途：COMMON
Restrictions on usage: NONE
使用に関する制限：なし
Author: Sean Turner
Author: Sean Turner
Change Controller: S/MIME working group delegated from the IESG
変更管理者：IESGから委任されたS/MIMEワーキンググループ
Type name: application
タイプ名：application
Subtype Name: pkcs7-signature
サブタイプ名：pkcs7-signature
Required Parameters: NONE
必要なパラメーター：なし
Optional Parameters: NONE
オプションのパラメーター：なし
Encoding Considerations: See Section 3 of this document
考慮事項のエンコード：このドキュメントのセクション3を参照してください
Security Considerations: See Section 6 of this document
セキュリティ上の考慮事項：このドキュメントのセクション6を参照してください
Interoperability Considerations: See Sections 1-6 of this document
相互運用性の考慮事項：このドキュメントのセクション1〜6を参照してください
Published Specification: RFC 2311, RFC 2633, and this document
公開された仕様：RFC 2311、RFC 2633、およびこのドキュメント
Applications that use this media type: Security applications Additional information: NONE
このメディアタイプを使用するアプリケーション：セキュリティアプリケーション追加情報：なし
Person & email to contact for further information: S/MIME working group chairs smime-chairs@tools.ietf.org
詳細問い合わせ先：S/MIMEワーキンググループ議長、smime-chairs@tools.ietf.org
Intended usage: COMMON
用途：COMMON
Restrictions on usage: NONE
使用に関する制限：なし
Author: Sean Turner
Author: Sean Turner
Change Controller: S/MIME working group delegated from the IESG
変更管理者：IESGから委任されたS/MIMEワーキンググループ
Cryptographic algorithms will be broken or weakened over time. Implementers and users need to check that the cryptographic algorithms listed in this document continue to provide the expected level of security. The IETF from time to time may issue documents dealing with the current state of the art. For example:
暗号アルゴリズムは時間の経過とともに破られたり、強度が低下したりします。実装者と利用者は、この文書に記載された暗号アルゴリズムが期待されるセキュリティ水準を引き続き提供しているか確認する必要があります。IETFは、その時点の最新状況を扱う文書を随時発行する場合があります。たとえば次のものがあります。
- The Million Message Attack described in RFC 3218 [MMA].
- RFC 3218 [MMA]に記載されている百万のメッセージ攻撃。
- The Diffie-Hellman "small-subgroup" attacks described in RFC 2785 [DHSUB].
- RFC 2785 [DHSUB]で説明されているDiffie-Hellmanの「小部分群」攻撃。
- The attacks against hash algorithms described in RFC 4270 [HASH-ATTACK].
- RFC 4270 [HASH-ATTACK]で説明されているハッシュアルゴリズムへの攻撃。
This specification uses Public-Key Cryptography technologies. It is assumed that the private key is protected to ensure that it is not accessed or altered by unauthorized parties.
この仕様では、パブリックキー暗号化技術を使用しています。秘密鍵は、許可されていない当事者によってアクセスまたは変更されないように保護されていると想定されています。
It is impossible for most people or software to estimate the value of a message's content. Further, it is impossible for most people or software to estimate the actual cost of recovering an encrypted message content 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 process a message's content. Thus, choosing between different key sizes (or choosing whether to just use plaintext) is also impossible for most people or software. 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.
多くの人やソフトウェアには、メッセージ内容の価値を見積もることができません。また、特定の鍵長で暗号化されたメッセージを復号する実際のコストも見積もれません。受信者が内容を処理できなかった場合の損失を見積もることも困難です。そのため、多くの人やソフトウェアには、鍵長を選ぶことや、平文を使うかどうかを判断することも困難です。それでも現実にはこうした判断が常に行われるため、この仕様では、アルゴリズム選択にその見積もりを使うための枠組みを示します。
The choice of 2048 bits as the RSA asymmetric key size in this specification is based on the desire to provide at least 100 bits of security. The key sizes that must be supported to conform to this specification seem appropriate for the Internet based on [STRENGTH]. Of course, there are environments, such as financial and medical systems, that may select different key sizes. For this reason, an implementation MAY support key sizes beyond those recommended in this specification.
この仕様でRSA非対称鍵のサイズとして2048ビットを選択したのは、少なくとも100ビットのセキュリティを提供したいという意図に基づいています。この仕様に準拠するためにサポートしなければならない鍵サイズは、[STRENGTH]に基づけば、インターネットにとって適切と思われます。もちろん、金融システムや医療システムなど、異なる鍵サイズを選択する可能性のある環境もあります。このため、実装は、この仕様で推奨されている以外の鍵サイズをサポートしてもよいです (MAY)。
Receiving agents that validate signatures and sending agents that encrypt messages need to be cautious of cryptographic processing usage when validating signatures and encrypting messages using keys larger than those mandated in this specification. An attacker could send certificates with keys that would result in excessive cryptographic processing, for example, keys larger than those mandated in this specification, which could swamp the processing element. Agents that use such keys without first validating the certificate to a trust anchor are advised to have some sort of cryptographic resource management system to prevent such attacks.
署名を検証する受信側エージェントとメッセージを暗号化する送信側エージェントは、この仕様で定めるものより長い鍵を使う場合、暗号処理に必要な資源に注意する必要があります。攻撃者は過度な暗号処理を引き起こす鍵を含む証明書を送り付けることができ、たとえば仕様で定めるより長い鍵によって処理装置を圧迫する可能性があります。信頼アンカーに対する証明書検証を行う前にそのような鍵を使うエージェントには、攻撃を防ぐ暗号資源管理機構を備えることが推奨されます。
Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of AES 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 no cryptography.
S/MIMEにおいて弱い暗号を使用することは、平文を送信することに対して実際のセキュリティをほとんど向上させません。しかし、AESの規定や、通信相手の当事者に対してより強力な暗号化能力を通知する機能など、S/MIMEの他の機能により、送信者は強力な暗号化を使用したメッセージを作成することができます。唯一の代替手段が暗号化をまったく使わないことである場合を除き、弱い暗号を使用することは決して推奨されません。
RSA and DSA keys of less than 1024 bits are now considered by many experts to be cryptographically insecure (due to advances in computing power), and should no longer be used to protect messages. Such keys were previously considered secure, so processing previously received signed and encrypted mail will often result in the use of weak keys. Implementations that wish to support previous versions of S/MIME or process old messages need to consider the security risks that result from smaller key sizes (e.g., spoofed messages) versus the costs of denial of service. If an implementation supports verification of digital signatures generated with RSA and DSA keys of less than 1024 bits, it MUST warn the user. Implementers should consider providing different warnings for newly received messages and previously stored messages. Server implementations (e.g., secure mail list servers) where user warnings are not appropriate SHOULD reject messages with weak signatures.
1024ビット未満のRSA鍵とDSA鍵は、計算能力の向上により、暗号学的に安全ではないと多くの専門家が考えており、メッセージ保護に使うべきではありません。以前は安全と考えられていたため、過去に受信した署名付き・暗号化メールの処理では、弱い鍵に遭遇することがあります。以前のS/MIMEバージョンへの対応や古いメッセージの処理を行う実装は、鍵長不足によるセキュリティリスク（偽造メッセージなど）とサービス拒否のコストを比較して検討する必要があります。1024ビット未満のRSA鍵またはDSA鍵で生成されたデジタル署名の検証に対応する実装は、利用者に警告しなければなりません (MUST)。実装者は、新しく受信したメッセージと以前から保存されているメッセージに対して、異なる警告を設けることを検討すべきです。利用者への警告が適切でないサーバー実装（セキュアなメーリングリストサーバーなど）は、弱い署名のメッセージを拒否すべきです (SHOULD)。
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 digital signatures.
実装者は、複数のアクティブなキーペアが1人の個人に関連付けられる可能性があることに注意すべきです (SHOULD)。たとえば、1つのキーペアを使用して機密性をサポートできますが、デジタル署名には別のキーペアを使用できます。
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で包むことなくEnvelopedDataを送信したり、その中にSignedDataを囲んだりする場合です。
If an implementation is concerned about compliance with National Institute of Standards and Technology (NIST) key size recommendations, then see [SP800-57].
実装が国立標準および技術研究所（NIST）の主要なサイズの推奨事項への準拠に懸念されている場合は、[SP800-57]を参照してください。
If messaging environments make use of the fact that a message is signed to change the behavior of message processing (examples would be running rules or UI display hints), without first verifying that the message is actually signed and knowing the state of the signature, this can lead to incorrect handling of the message. Visual indicators on messages may need to have the signature validation code checked periodically if the indicator is supposed to give information on the current status of a message.
メッセージング環境が、署名検証を行わず、署名の状態も確認しないまま、メッセージが署名されているという事実を使って処理方法（ルールの実行やUI表示のヒントなど）を変えると、誤った処理につながる可能性があります。メッセージの現在の状態を示すことが目的なら、視覚的な表示が参照する署名検証コードを定期的に確認する必要がある場合があります。
[CERT32] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010.
[CERT32] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010.
[CHARSETS] Character sets assigned by IANA. See http://www.iana.org/assignments/character-sets.
[CHARSETS] Character sets assigned by IANA. See http://www.iana.org/assignments/character-sets.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSCOMPR] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[CMSCOMPR] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[CMS-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[CMS-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[CONTDISP] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[CONTDISP] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[FIPS186-2] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS Publication 186-2, January 2000. [With Change Notice 1].
[FIPS186-2] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS Publication 186-2, January 2000. [With Change Notice 1].
[FIPS186-3] National Institute of Standards and Technology (NIST), FIPS Publication 186-3: Digital Signature Standard, June 2009.
[FIPS186-3] National Institute of Standards and Technology (NIST), FIPS Publication 186-3: Digital Signature Standard, June 2009.
[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-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC2634] Hoffman, P. Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[RFC2634] Hoffman, P. Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[RSAOAEP] Housley, R. "Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[RSAOAEP] Housley, R. "Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[RSAPSS] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, June 2005.
[RSAPSS] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, June 2005.
[SP800-56A] National Institute of Standards and Technology (NIST), Special Publication 800-56A: Recommendation Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised), March 2007.
[SP800-56A] National Institute of Standards and Technology (NIST), Special Publication 800-56A: Recommendation Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised), March 2007.
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[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., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.
[HASH-ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[HASH-ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[MMA] Rescorla, E., "Preventing the Million Message Attack on Cryptographic Message Syntax", RFC 3218, January 2002.
[MMA] Rescorla, E., "Preventing the Million Message Attack on Cryptographic Message Syntax", RFC 3218, January 2002.
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, "S/MIME Version 2 Certificate Handling", RFC 2312, March 1998.
[RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, "S/MIME Version 2 Certificate Handling", RFC 2312, March 1998.
[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998.
[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998.
[RFC2315] Kaliski, B., "PKCS #7: Certification Message Syntax Version 1.5", RFC 2315, March 1998.
[RFC2315] Kaliski, B., "PKCS #7: Certification Message Syntax Version 1.5", RFC 2315, March 1998.
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999.
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999.
[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[SP800-57] National Institute of Standards and Technology (NIST), Special Publication 800-57: Recommendation for Key Management, August 2005.
[SP800-57] National Institute of Standards and Technology (NIST), Special Publication 800-57: Recommendation for Key Management, August 2005.
[STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
Note: The ASN.1 module contained herein is unchanged from RFC 3851 [SMIMEv3.1] with the exception of a change to the prefersBinaryInside ASN.1 comment. This module uses the 1988 version of ASN.1.
注：ここに含まれるASN.1モジュールは、prefersBinaryInside ASN.1コメントの変更を除き、RFC 3851 [SMIMEv3.1]から変更されていません。このモジュールはASN.1の1988年版を使います。
SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax [CMS]
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) };
-- id-aa is the arc with all new authenticated and unauthenticated
-- attributes produced by the S/MIME Working Group
id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
-- S/MIME Capabilities provides a method of broadcasting the
-- symmetric capabilities understood. Algorithms SHOULD be ordered
-- by preference and grouped by type
smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL }
SMIMECapabilities ::= SEQUENCE OF SMIMECapability
-- Encryption Key Preference provides a method of broadcasting the
-- preferred encryption certificate.
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}
-- receipentKeyId is spelt incorrectly, but kept for historical
-- reasons.
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
-- The preferBinaryInside OID indicates an ability to receive
-- messages with binary encoding inside the CMS wrapper.
-- The preferBinaryInside attribute's value field is ABSENT.
id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
-- The following list OIDs to be used with S/MIME V3
-- Signature Algorithms Not Found in [CMSALG], [CMS-SHA2], [RSAPSS],
-- and [RSAOAEP]
--
-- 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.
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
-- (RC2 Key Length (number of bits))
END
The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document) are backwards compatible with the S/MIME v2 Message Specification [SMIMEv2], with the exception of the algorithms (dropped RC2/40 requirement and added DSA and RSASSA-PSS requirements). Therefore, it is recommended that RFC 2311 [SMIMEv2] be moved to Historic status.
S/MIME v3 [SMIMEv3]、v3.1 [SMIMEv3.1]、v3.2（この文書）は、アルゴリズムに関する変更（RC2/40の要件を削除し、DSAとRSASSA-PSSの要件を追加した点）を除いて、S/MIME v2メッセージ仕様[SMIMEv2]と後方互換です。そのため、RFC 2311 [SMIMEv2]をHistoric状態へ移行することが推奨されます。
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. Without v2, there wouldn't be a v3, v3.1, or v3.2.
S/MIMEバージョン2メッセージ仕様RFCの共著者であるSteve Dusse、Paul Hoffman、Laurence Lundblade、Lisa Repkaに感謝します。v2がなければ、v3、v3.1、v3.2もありませんでした。
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 because they made direct contributions to this document:
S/MIMEワーキンググループの多くのメンバーも、この文書の作成に尽力し貢献しました。すべての人を挙げることはできないため、その点をお詫びします。以下に、直接貢献した人々をアルファベット順に記します。
Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, John Pawling, and Jim Schaad.
Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, John Pawling, and Jim Schaad.
Authors' Addresses
著者のアドレス
Blake Ramsdell Brute Squad Labs, Inc.
Blake Ramsdell Brute Squad Labs, Inc.
EMail: blaker@gmail.com
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
EMail: turners@ieca.com