[要約] RFC 3851は、S/MIMEバージョン3.1メッセージ仕様に関する規格であり、電子メールのセキュリティと認証を向上させるために設計されています。このRFCの目的は、メールの暗号化、署名、認証、およびデジタル証明書の使用に関する標準化を提供することです。
Network Working Group B. Ramsdell, Editor
Request for Comments: 3851 Sendmail, Inc.
Obsoletes: 2633 July 2004
Category: Standards Track
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification
セキュア/多目的インターネットメールエクステンション（S/MIME）バージョン3.1メッセージ仕様
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633.
このドキュメントでは、Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1を定義しています。S/MIMEは、安全なMIMEデータを送信および受信するための一貫した方法を提供します。デジタル署名は、認証、メッセージの整合性、および繰り返しの証明を伴う非繰り返しを提供します。暗号化はデータの機密性を提供します。圧縮は、データサイズを削減するために使用できます。このドキュメントは、RFC 2633を廃止します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification Overview . . . . . . . . . . . . . . . . . 3
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Definitions. . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Compatibility with Prior Practice of S/MIME. . . . . . . 5
1.5. Changes Since S/MIME v3. . . . . . . . . . . . . . . . . 5
2. CMS Options. . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. DigestAlgorithmIdentifier. . . . . . . . . . . . . . . . 5
2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 6
2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 6
2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 6
2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 7
2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 11
2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 12
3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . . 14
3.1. Preparing the MIME Entity for Signing, Enveloping
or Compressing . . . . . . . . . . . . . . . . . . . . . 14
3.2. The application/pkcs7-mime Type. . . . . . . . . . . . . 19
3.3. Creating an Enveloped-only Message . . . . . . . . . . . 21
3.4. Creating a Signed-only Message . . . . . . . . . . . . . 22
3.5. Creating an Compressed-only Message. . . . . . . . . . . 26
3.6. Multiple Operations. . . . . . . . . . . . . . . . . . . 27
3.7. Creating a Certificate Management Messagetoc . . . . . . 27
3.8. Registration Requests. . . . . . . . . . . . . . . . . . 28
3.9. Identifying an S/MIME Message. . . . . . . . . . . . . . 28
4. Certificate Processing . . . . . . . . . . . . . . . . . . . . 29
4.1. Key Pair Generation. . . . . . . . . . . . . . . . . . . 29
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
B. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
B.1. Normative References . . . . . . . . . . . . . . . . . . 32
B.2. Informative References . . . . . . . . . . . . . . . . . 34
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
D. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures), and data confidentiality (using encryption).
S/MIME（Secure/Multipurpose Internet Mail Extensions）は、安全なMIMEデータを送信および受信するための一貫した方法を提供します。人気のあるインターネットMIME標準に基づいて、S/MIMEは、電子メッセージングアプリケーションに次の暗号化セキュリティサービスを提供します。認証、メッセージの整合性、原産地の非repudiation（デジタル署名を使用）、およびデータの機密性（暗号化を使用）。
S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems.
S/MIMEは、従来のメールユーザーエージェント（MUAS）で使用されて、送信されるメールに暗号化セキュリティサービスを追加し、受信したメールで暗号化セキュリティサービスを解釈することができます。ただし、s/mimeはメールに制限されていません。HTTPなどのMIMEデータを輸送する任意の輸送メカニズムで使用できます。そのため、S/MIMEはMIMEのオブジェクトベースの機能を利用して、混合輸送システムで安全なメッセージを交換できるようにします。
Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet.
さらに、S/MIMEは、ソフトウェアで生成されたドキュメントの署名やインターネット経由で送信されたFAXメッセージの暗号化など、人間の介入を必要としない暗号化セキュリティサービスを使用する自動化されたメッセージ転送エージェントで使用できます。
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. The MIME standard [MIME-SPEC] provides a general structure for the content type of Internet messages and allows extensions for new content type applications.
このドキュメントでは、暗号化署名および暗号化サービスをMIMEデータに追加するためのプロトコルについて説明します。MIME標準[MIME-SPEC]は、コンテンツタイプのインターネットメッセージの一般的な構造を提供し、新しいコンテンツタイプアプリケーションの拡張機能を可能にします。
This specification defines how to create a MIME body part that has been cryptographically enhanced according to CMS [CMS], which is derived from PKCS #7 [PKCS-7]. This specification also defines the application/pkcs7-mime MIME type that can be used to transport those body parts.
この仕様は、PKCS＃7 [PKCS-7]に由来するCMS [CMS]に従って暗号化されたマイムボディパーツを作成する方法を定義します。この仕様では、それらの身体部分の輸送に使用できるアプリケーション/PKCS7-MIME MIMEタイプも定義します。
This document also discusses how to use the multipart/signed MIME type defined in [MIME-SECURE] to transport S/MIME signed messages. multipart/signed is used in conjunction with the application/pkcs7- signature MIME type, which is used to transport a detached S/MIME signature.
このドキュメントでは、[Mime-Secure]で定義されたMultiPart/署名されたMimeタイプを使用して、S/MIME署名されたメッセージを輸送する方法についても説明します。MultiPart/Signedは、アプリケーション/PKCS7-シグネチャーMIMEタイプと組み合わせて使用されます。
In order to create S/MIME messages, an S/MIME agent MUST follow the specifications in this document, as well as the specifications listed in the Cryptographic Message Syntax document [CMS] [CMSALG].
S/MIMEメッセージを作成するには、S/MIMEエージェントは、このドキュメントの仕様と、暗号化メッセージSyntaxドキュメント[CMS] [CMSAlg]にリストされている仕様に従う必要があります。
Throughout this specification, there are requirements and recommendations made for how receiving agents handle incoming messages. There are separate requirements and recommendations for how sending agents create outgoing messages. In general, the best strategy is to "be liberal in what you receive and conservative in what you send". Most of the requirements are placed on the handling of incoming messages while the recommendations are mostly on the creation of outgoing messages.
この仕様を通して、受信エージェントが着信メッセージを処理する方法については、要件と推奨事項があります。エージェントを送信する方法については、発信メッセージを作成する方法については、個別の要件と推奨事項があります。一般的に、最良の戦略は、「あなたが受け取るものにおいてリベラルであり、あなたが送るものに保守的になる」ことです。要件のほとんどは、着信メッセージの処理に配置されていますが、推奨事項は主に発信メッセージの作成にあります。
The separation for requirements on receiving agents and sending agents also derives from the likelihood that there will be S/MIME systems that involve software other than traditional Internet mail clients. S/MIME can be used with any system that transports MIME data. An automated process that sends an encrypted message might not be able to receive an encrypted message at all, for example. Thus, the requirements and recommendations for the two types of agents are listed separately when appropriate.
受信エージェントと送信エージェントの要件の分離は、従来のインターネットメールクライアント以外のソフトウェアを含むS/MIMEシステムが存在する可能性からも派生しています。S/MIMEは、MIMEデータを輸送する任意のシステムで使用できます。暗号化されたメッセージを送信する自動化されたプロセスでは、たとえば、暗号化されたメッセージをまったく受信できない場合があります。したがって、2種類のエージェントの要件と推奨事項は、必要に応じて個別にリストされます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUSTSHOULD].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[必須]に記載されているように解釈される。
For the purposes of this specification, the following definitions apply.
この仕様の目的のために、次の定義が適用されます。
ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208 [X.208-88].
ASN.1：CCITT X.208 [X.208-88]で定義されている要約構文表記1。
BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209 [X.209-88].
BER：CCITT X.209 [X.209-88]で定義されているASN.1の基本エンコードルール。
Certificate: A type that binds an entity's name to a public key with a digital signature.
証明書：エンティティの名前をデジタル署名を使用して公開キーにバインドするタイプ。
DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT X.509 [X.509-88].
Der：CCITT X.509 [X.509-88]で定義されているASN.1の識別エンコードルール。
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エージェント：受信エージェント、送信エージェント、またはその両方であるユーザーソフトウェア。
S/MIME version 3.1 agents SHOULD attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive and S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive. RFC 2311 also has historical information about the development of S/MIME.
S/MIMEバージョン3.1エージェントは、S/MIMEの以前のバージョンのエージェントと可能な限り最大の相互運用性を持つことを試みる必要があります。S/MIMEバージョン2はRFC 2311からRFC 2315で説明されています。インクルーシブおよびS/MIMEバージョン3は、RFC 2630からRFC 2634 Inclusiveで説明されています。RFC 2311には、S/MIMEの開発に関する歴史的情報もあります。
The RSA public key algorithm was changed to a MUST implement key wrapping algorithm, and the Diffie-Hellman algorithm changed to a SHOULD implement.
RSAの公開キーアルゴリズムは、a必要のあるキーラッピングアルゴリズムに変更され、diffie-hellmanアルゴリズムが実装されたAに変更されました。
The AES symmetric encryption algorithm has been included as a SHOULD implement.
AES対称暗号化アルゴリズムは、実装する必要があるものとして含まれています。
The RSA public key algorithm was changed to a MUST implement signature algorithm.
RSA公開キーアルゴリズムは、署名アルゴリズムを実装する必要があるように変更されました。
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.
証明書を送信するために「空の」署名dataメッセージの使用に関するあいまいな言語は、証明書の取り消しリストの送信も許可されていることを反映するために明確にされました。
The use of binary encoding for some MIME entities is now explicitly discussed.
一部のMIMEエンティティのバイナリエンコーディングの使用については、現在明示的に説明しています。
Header protection through the use of the message/rfc822 MIME type has been added.
メッセージ/RFC822 MIMEタイプの使用によるヘッダー保護が追加されました。
Use of the CompressedData CMS type is allowed, along with required MIME type and file extension additions.
必要なMIMEタイプとファイルエクステンションの追加とともに、圧縮されたData CMSタイプの使用が許可されています。
CMS allows for a wide variety of options in content and algorithm support. This section puts forth a number of support requirements and recommendations in order to achieve a base level of interoperability among all S/MIME implementations. [CMSALG] provides additional details regarding the use of the cryptographic algorithms.
CMSは、コンテンツとアルゴリズムのサポートにさまざまなオプションを可能にします。このセクションでは、すべてのS/MIME実装の間で相互運用性の基本レベルを達成するために、多くのサポート要件と推奨事項を示します。[CMSALG]は、暗号化アルゴリズムの使用に関する追加の詳細を提供します。
Sending and receiving agents MUST support SHA-1 [CMSALG]. Receiving agents SHOULD support MD5 [CMSALG] for the purpose of providing backward compatibility with MD5-digested S/MIME v2 SignedData objects.
送信および受信エージェントは、SHA-1 [CMSALG]をサポートする必要があります。受信エージェントは、MD5デザインのS/MIME V2 SignedDataオブジェクトとの後方互換性を提供する目的で、MD5 [CMSALG]をサポートする必要があります。
Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. The algorithm parameters MUST be absent (not encoded as NULL). Receiving agents MUST support rsaEncryption, defined in [CMSALG].
受信エージェントは、[cmsalg]で定義されているid-dsa-with-sha1をサポートする必要があります。アルゴリズムパラメーターは存在しない必要があります（nullとしてエンコードされていません）。受信エージェントは、[cmsalg]で定義されているrsaencryptionをサポートする必要があります。
Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
送信エージェントは、id-dsa-with-sha1またはrsaencryptionのいずれかをサポートする必要があります。
If using rsaEncryption, sending and receiving agents MUST support the digest algorithms in section 2.1 as specified.
rsaencryptionを使用している場合、指定されているようにセクション2.1のダイジェストアルゴリズムを送信および受信エージェントがサポートする必要があります。
Note that S/MIME v3 clients might only implement signing or signature verification using id-dsa-with-sha1, and might also use id-dsa as an AlgorithmIdentifier in this field. Receiving clients SHOULD recognize id-dsa as equivalent to id-dsa-with-sha1, and sending clients MUST use id-dsa-with-sha1 if using that algorithm. Also note that S/MIME v2 clients are only required to verify digital signatures using the rsaEncryption algorithm with SHA-1 or MD5, and might not implement id-dsa-with-sha1 or id-dsa at all.
S/MIME V3クライアントは、ID-DSA-With-Sha1を使用してSINGILSまたはSIGNATURE検証のみを実装し、このフィールドのAlgorithMidentifierとしてID-DSAを使用する場合があることに注意してください。受信クライアントは、ID-DSAをID-DSA-With-Sha1に相当するものとして認識し、そのアルゴリズムを使用する場合はクライアントに送信する必要がある場合は、ID-DSA-With-Sha1を使用する必要があります。また、S/MIME V2クライアントは、SHA-1またはMD5を使用したRSAENCRYPTIONアルゴリズムを使用してデジタル署名を検証するためにのみ必要であり、ID-DSA With-Sha1またはID-DSAを実装しない場合があることに注意してください。
Sending and receiving agents MUST support rsaEncryption, defined in [CMSALG].
送信および受信エージェントは、[cmsalg]で定義されているrsaencryptionをサポートする必要があります。
Sending and receiving agents SHOULD support Diffie-Hellman defined in [CMSALG], using the ephemeral-static mode.
エージェントの送信と受信エージェントは、一時的な静的モードを使用して、[CMSAlg]で定義されたDiffie-Hellmanをサポートする必要があります。
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クライアントは、Diffie-Hellmanアルゴリズムを使用してキー暗号化と復号化のみを実装できることに注意してください。また、S/MIME V2クライアントは、RSAECNICRYPTINGアルゴリズムを使用してコンテンツ暗号化キーを復号化することができることに注意してください。
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には、データ、SignedData、EnvelopedData、および圧縮されたDataコンテンツタイプのみが使用されています。
Sending agents MUST use the id-data content type identifier to identify the "inner" MIME message content. For example, when applying a digital signature to MIME data, the CMS SignedData encapContentInfo eContentType MUST include the id-data object identifier and the MIME content MUST be stored in the SignedData encapContentInfo eContent OCTET STRING (unless the sending agent is using multipart/signed, in which case the eContent is absent, per 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.
送信エージェントは、ID-DATAコンテンツタイプ識別子を使用して、「内側の」MIMEメッセージコンテンツを識別する必要があります。たとえば、MIMEデータにデジタル署名を適用する場合、CMS SignedData EncapContentInfo EcontentTypeはID-Dataオブジェクト識別子を含める必要があり、MIMEコンテンツはSignedData EncapContentInfo Econtent Octet文字列に保存する必要があります（送信エージェントがMultiPART/SIGNEDを使用しない限り、この場合、このドキュメントのセクション3.4.3に従って、econtentが存在しません）。別の例として、MIMEデータに暗号化を適用する場合、CMS EnvelopedData暗号化されたContentInfo contentTypeを含める必要があり、暗号化されたMIMEコンテンツを封入したMIMEコンテンツに保存する必要があります。
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コンテンツタイプを使用して、デジタル署名をメッセージに適用する必要があります。署名情報がない退化した場合、証明書を伝える必要があります。メッセージに署名を適用すると、認証、メッセージの整合性、および原点の非和解が提供されます。
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 message 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 to be included along with a signature.
SignerINFOタイプにより、署名と署名の属性を含めることができます。
Receiving agents MUST be able to handle zero or one instance of each of the signed attributes listed here. Sending agents SHOULD generate one instance of each of the following signed attributes in each S/MIME message:
受信エージェントは、ここにリストされている各署名属性のゼロまたは1つのインスタンスを処理できる必要があります。送信エージェントは、各S/MIMEメッセージに次の各署名属性の1つのインスタンスを生成する必要があります。
- signingTime (section 2.5.1 in this document) - sMIMECapabilities (section 2.5.2 in this document) - sMIMEEncryptionKeyPreference (section 2.5.3 in this document) - id-messageDigest (section 11.2 in [CMS]) - id-contentType (section 11.1 in [CMS]) Further, receiving agents SHOULD be able to handle zero or one instance in the signingCertificate signed attribute, as defined in section 5 of [ESS].
- 署名時間（このドキュメントのセクション2.5.1） - SmimeCapability（このドキュメントのセクション2.5.2） - SmimeCryptionKeypreference（このドキュメントのセクション2.5.3） - id -messagedigest（[cms] in [cms] in [cms]） - id -contenttype（セクションさらに、[cms]で）、受信エージェントは、[ess]のセクション5で定義されているように、signingcertificate署名属性のゼロまたは1つのインスタンスを処理できる必要があります。
Sending agents SHOULD generate one instance of the signingCertificate signed attribute in each SignerInfo structure.
送信エージェントは、各SignerInfo構造にSigningCertificate署名属性の1つのインスタンスを生成する必要があります。
Additional attributes and values for these attributes might be defined in the future. Receiving agents SHOULD handle attributes or values that it does not recognize in a graceful manner.
これらの属性の追加の属性と値は、将来定義される場合があります。受信エージェントは、優雅な方法で認識されない属性または値を処理する必要があります。
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.
ここにリストされていない署名属性を含むインタラクティブな送信エージェントは、ユーザーが署名されているすべてのデータを認識できるように、ユーザーにそれらの属性を表示する必要があります。
The signing-time attribute is used to convey the time that a message was signed. The time of signing will most likely be created by a message originator and therefore is only as trustworthy as the originator.
署名時の属性は、メッセージが署名された時間を伝えるために使用されます。署名の時間は、おそらくメッセージのオリジネーターによって作成される可能性が高いため、オリジネーターと同じくらい信頼できます。
Sending agents MUST encode signing time through the year 2049 as UTCTime; signing times in 2050 or later MUST be encoded as GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST interpret the year field (YY) as follows:
送信エージェントは、2049年までの署名時間をUTCTIMEとしてエンコードする必要があります。2050年以降の署名時間は、一般化された時間としてエンコードする必要があります。UTCTIMEの選択を使用する場合、S/MIMEエージェントは次のように年度分野（YY）を解釈する必要があります。
if YY is greater than or equal to 50, the year is interpreted as 19YY; if YY is less than 50, the year is interpreted as 20YY.
YYが50以上の場合、年は19yyと解釈されます。YYが50未満の場合、年は20YYと解釈されます。
The SMIMECapabilities attribute includes signature algorithms (such as "sha1WithRSAEncryption"), symmetric algorithms (such as "DES-EDE3-CBC"), and key encipherment algorithms (such as "rsaEncryption"). There are also several identifiers which indicate support for other optional features such as binary encoding and compression. The SMIMECapabilities were designed to be flexible and extensible so that, in the future, a means of identifying other capabilities and preferences such as certificates can be added in a way that will not cause current clients to break.
SmimeCapabilities属性には、署名アルゴリズム（「Sha1withrsaencryption」など）、対称アルゴリズム（「des-ede3-cbc」など）、およびキーエンカーメントアルゴリズム（「rsaencryption」など）が含まれます。また、バイナリエンコードや圧縮など、他のオプション機能のサポートを示すいくつかの識別子もあります。SmimeCapabilityは、将来的には、現在のクライアントが壊れない方法で証明書などの他の機能や好みを識別する手段を将来的に識別する手段として柔軟に拡張できるように設計されています。
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属性は署名誘導でなければなりません。署名されていないものであってはなりません。CMSは、SigneDattributesを一連の属性として定義します。SignerInfoのSigneDattributesには、SmimeCapability属性の複数のインスタンスを含めてはなりません。CMSは、属性のasn.1構文を定義して、属性の属性セットを含むようにします。SmimeCapabilities属性には、属性の単一インスタンスのみを含める必要があります。属性の属性セットに存在するゼロまたは複数のインスタンスが存在してはなりません。
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属性のセマンティクスは、SmimeCapabilityを発表するクライアントがサポートできるものに関する部分的なリストを指定します。クライアントは、サポートするすべての機能をリストする必要はなく、機能リストがあまり長くならないようにすべての機能をリストする必要はありません。SmimeCapabilities属性では、オブジェクト識別子（OID）が好みの順にリストされますが、カテゴリの線に沿って論理的に分離する必要があります（署名アルゴリズム、対称アルゴリズム、キーエンコリメントアルゴリズムなど）
The structure of the SMIMECapabilities attribute is to facilitate simple table lookups and binary comparisons in order to determine matches. For instance, the DER-encoding for the SMIMECapability for DES EDE3 CBC MUST be identically encoded regardless of the implementation. Because of the requirement for identical encoding, individuals documenting algorithms to be used in the SMIMECapabilities attribute SHOULD explicitly document the correct byte sequence for the common cases.
SmimeCapability属性の構造は、一致を決定するために、単純なテーブル検索とバイナリ比較を促進することです。たとえば、DES EDE3 CBCのSmimecapabilityのderエンコードは、実装に関係なく同一にエンコードする必要があります。同一のエンコーディングの要件があるため、SmimeCapability属性で使用されるアルゴリズムを文書化する個人は、共通の場合の正しいバイトシーケンスを明示的に文書化する必要があります。
For any capability, the associated parameters for the OID MUST specify all of the parameters necessary to differentiate between two instances of the same algorithm. For instance, the number of rounds and the block size for RC5 needs to be specified in addition to the key length.
任意の機能については、OIDの関連するパラメーターは、同じアルゴリズムの2つのインスタンスを区別するために必要なすべてのパラメーターを指定する必要があります。たとえば、キーの長さに加えて、RC5のラウンド数とブロックサイズを指定する必要があります。
The OIDs that correspond to algorithms SHOULD use the same OID as the actual algorithm, except in the case where the algorithm usage is ambiguous from the OID. For instance, in an earlier specification, rsaEncryption was ambiguous because it could refer to either a signature algorithm or a key encipherment algorithm. In the event that an OID is ambiguous, it needs to be arbitrated by the maintainer of the registered SMIMECapabilities list as to which type of algorithm will use the OID, and a new OID MUST be allocated under the smimeCapabilities OID to satisfy the other use of the OID.
アルゴリズムの使用がOIDからあいまいである場合を除き、アルゴリズムに対応するOIDは実際のアルゴリズムと同じOIDを使用する必要があります。たとえば、以前の仕様では、rsaencryptionは、署名アルゴリズムまたはキーエンコリメントアルゴリズムのいずれかを参照できるため、あいまいでした。OIDが曖昧な場合は、どのタイプのアルゴリズムがOIDを使用するかについて、登録されたスミメバティアビリティリストのメンテナーによって仲裁する必要があり、新しいOIDをSmimeCapabilitivities OIDの下で割り当てる必要があります。oid。
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.
登録されたSmimeCapability Listは、それらを必要とするOIDのパラメーター、特に可変長対称暗号の場合の重要な長さを指定します。特定のOIDに差別化されたパラメーターがない場合、パラメーターを省略する必要があり、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.
SmimeCapability属性の追加値は、将来定義される場合があります。受信エージェントは、優雅な方法で認識されない値を持つSmimeCapabilitiesオブジェクトを処理する必要があります。
Section 2.7.1 explains a strategy for caching capabilities.
セクション2.7.1では、キャッシュ機能の戦略について説明します。
For the RC2 algorithm preference SMIMECapability, the capabilityID MUST be set to the value rc2-cbc as defined in [CMSALG]. The parameters field MUST contain SMIMECapabilitiesParametersForRC2CBC (see appendix A).
RC2アルゴリズムの好みのSmimecapabilityの場合、[CMSAlg]で定義されているように、能力IDを値RC2-CBCに設定する必要があります。パラメーターフィールドには、SmimeCapabilityParametersForrc2CBCを含める必要があります（付録Aを参照）。
Please note that the SMIMECapabilitiesParametersForRC2CBC is a single INTEGER which contains the effective key length (NOT the corresponding RC2 parameter version value). So, for example, for RC2 with a 128-bit effective key length, the parameter would be encoded as the INTEGER value 128, NOT the corresponding parameter version of 58.
SmimeCapabilityParametersForrc2CBCは、有効なキー長を含む単一の整数であることに注意してください（対応するRC2パラメーターバージョン値ではありません）。したがって、たとえば、128ビットの有効キー長を持つRC2の場合、パラメーターは58の対応するパラメーターバージョンではなく、整数値128としてエンコードされます。
The encryption key preference attribute allows the signer to unambiguously describe which of the signer's certificates has the signer's preferred encryption key. This attribute is designed to enhance behavior for interoperating with those clients that use separate keys for encryption and signing. This attribute is used to convey to anyone viewing the attribute which of the listed certificates is appropriate for encrypting a session key for future encrypted messages.
暗号化キー設定属性により、署名者は署名者の証明書のどれが署名者の優先暗号化キーを持っているかを明確に説明できます。この属性は、暗号化と署名に個別のキーを使用するクライアントとの相互運用の動作を強化するように設計されています。この属性は、属性を表示する人に伝達されるために使用されます。これは、将来の暗号化されたメッセージのセッションキーを暗号化するのに適しています。
If present, the SMIMEEncryptionKeyPreference attribute MUST be a SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A SMIMEEncryptionKeyPreference attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
存在する場合、SmimeCryptionKeypreference属性はSigneDattributeでなければなりません。署名されていないものであってはなりません。CMSは、SigneDattributesを一連の属性として定義します。SignerInfoのSigneDattributesには、SmimeCryptingKeypreference属性の複数のインスタンスを含めてはなりません。CMSは、属性のasn.1構文を定義して、属性の属性セットを含むようにします。SmimeCryptingKeypreference属性には、属性の単一インスタンスのみを含める必要があります。属性の属性セットに存在するゼロまたは複数のインスタンスが存在してはなりません。
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.
送信エージェントには、この属性が使用されている場合、署名されたメッセージに含まれる証明書のセットに参照される証明書を含める必要があります。それが以前に受信エージェントが利用できるようになった場合、証明書は省略される場合があります。送信エージェントは、一般的に使用されるまたは優先される暗号化証明書がメッセージに署名するために使用される証明書と同じではない場合は、この属性を使用する必要があります。
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.
受信エージェントは、メッセージの署名が有効であり、署名時間が現在保存されている値よりも大きい場合は、優先データを保存する必要があります。（SmimimeCapabilityと同様に、クロックスキューをチェックし、スキューが大きすぎる場合はデータを使用しないでください。）受信エージェントは、可能であれば、送信者の暗号化キー設定属性を尊重する必要があります。ただし、これは優先権のみを表し、受信エージェントは有効な送信者に返信する際に任意の証明書を使用できます。
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包括的なデータメッセージを送信するときに使用する主要な管理証明書を決定するには、次の手順に従う必要があります。
- 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.
- SmimeCryctingKeypreference属性が、目的の受信者から受信したSignedDataオブジェクトにある場合、これは受信者のX.509キー管理証明書として使用する必要があるX.509証明書を識別します。
- If an SMIMEEncryptionKeyPreference attribute is not found in a SignedData object received from the desired recipient, the set of X.509 certificates SHOULD be searched for a X.509 certificate with the same subject name as the signing of a X.509 certificate which can be used for key management.
- smimecryctrincekeypreference属性が目的の受信者から受信したsignedDataオブジェクトに属性がない場合、x.509証明書のセットは、x.509証明書の署名と同じ件名名を持つx.509証明書を検索する必要があります。キー管理に使用されます。
- Or use some other method of determining the user's key management key. If a X.509 key management certificate is not found, then encryption cannot be done with the signer of the message. If multiple X.509 key management certificates are found, the S/MIME agent can make an arbitrary choice between them.
- または、ユーザーのキー管理キーを決定する他の方法を使用します。X.509キー管理証明書が見つからない場合、メッセージの署名者で暗号化を行うことはできません。複数のX.509キー管理証明書が見つかった場合、S/MIMEエージェントはそれらの間で任意の選択をすることができます。
S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as well as subjectKeyIdentifier. Messages that use the subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
S/MIME v3.1実装は、subjecteyidentifierと同様に、発行者と登場者の両方をサポートする必要があります。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の値を使用していることを理解することが重要です。潜在的に異なるエンティティの複数の証明書に実装を準備する必要があります。これは、件名の条件を示す前に、署名検証中に各マッチング証明書を試す準備をする必要があります。
Sending and receiving agents MUST support encryption and decryption with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Receiving agents SHOULD support encryption and decryption using the RC2 [CMSALG] or a compatible algorithm at a key size of 40 bits, hereinafter called "RC2/40". Sending and receiving agents SHOULD support encryption and decryption with AES [CMSAES] at a key size of 128, 192, and 256 bits.
送信および受信エージェントは、DES EDE3 CBCで暗号化と復号化をサポートする必要があります。受信エージェントは、「RC2/40」と呼ばれる40ビットのキーサイズでRC2 [CMSALG]または互換性のあるアルゴリズムを使用した暗号化と復号化をサポートする必要があります。送信および受信エージェントは、128、192、および256ビットのキーサイズでAES [CMSAE]で暗号化と復号化をサポートする必要があります。
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では、送信エージェントがオプションで、とりわけ、その選好の順に復号化される機能をオプションで発表できる方法を定義します。着信符号付きメッセージで暗号化機能属性を処理および記憶するための次の方法を使用する必要があります。
- 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.
- 受信エージェントが送信者の公開キーの機能のリストをまだ作成していない場合、着信メッセージの署名を確認してタイムスタンプをチェックした後、受信エージェントは少なくとも署名時間と対称を含む新しいリストを作成する必要があります機能。
- 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.
- そのようなリストが既に存在する場合、受信エージェントは、着信メッセージの署名時間がリストに保存されている署名時間よりも大きいこと、および署名が有効であることを確認する必要があります。その場合、受信エージェントは、リスト内の署名時間と機能の両方を更新する必要があります。将来的には遠くにある署名時間の値（つまり、合理的な時計のスキューよりも大きな矛盾）、または署名を検証できないメッセージの機能リストは受け入れてはなりません。
The list of capabilities SHOULD be stored for future use in creating messages.
機能のリストは、メッセージの作成に将来使用するために保存する必要があります。
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 such as RC2/40. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use.
メッセージを送信する前に、送信エージェントは、メッセージ内の特定のデータに弱い暗号化を使用する意思があるかどうかを決定する必要があります。送信エージェントがこのデータに対して弱い暗号化が受け入れられないと判断した場合、送信エージェントはRC2/40などの弱いアルゴリズムを使用してはなりません。弱い暗号化を使用または使用しないという決定は、このセクションで使用する暗号化アルゴリズムについて他の決定を上書きします。
Sections 2.7.2.1 through 2.7.2.4 describe the decisions a sending agent SHOULD use in deciding which type of encryption will be applied to a message. These rules are ordered, so the sending agent SHOULD make its decision in the order given.
セクション2.7.2.1から2.7.2.4は、送信エージェントがメッセージに適用される暗号化のタイプを決定する際に使用すべき決定について説明します。これらのルールは順序付けられているため、送信エージェントは与えられた順序で決定を下す必要があります。
If the sending agent has received a set of capabilities from the recipient for the message the agent is about to encrypt, then the sending agent SHOULD use that information by selecting the first capability in the list (that is, the capability most preferred by the intended recipient) that the sending agent knows how to encrypt. The sending agent SHOULD use one of the capabilities in the list if the agent reasonably expects the recipient to be able to decrypt the message.
送信エージェントが受信者からメッセージのセットを受信している場合、エージェントが暗号化しようとしている場合、送信エージェントはリスト内の最初の機能（つまり、意図されたものが最も好む機能を選択してその情報を使用する必要があります。受信者）送信エージェントが暗号化する方法を知っていること。エージェントが受信者がメッセージを解読できることを合理的に期待している場合、送信エージェントはリスト内の機能の1つを使用する必要があります。
If the following two conditions are met: - the sending agent has no knowledge of the encryption capabilities of the recipient, - and the sending agent has no knowledge of the version of S/MIME of the recipient, then the sending agent SHOULD use tripleDES because it is a stronger algorithm and is required by S/MIME v3. If the sending agent chooses not to use tripleDES in this step, it SHOULD use RC2/40.
次の2つの条件が満たされている場合 - - 送信エージェントには、レシピエントの暗号化機能に関する知識がなく、送信中のエージェントにはレシピエントのS/MIMEのバージョンに関する知識がない場合、送信エージェントは3倍を使用する必要があります。これはより強力なアルゴリズムであり、S/MIME V3で必要です。送信エージェントがこのステップで3倍を使用しないことを選択した場合、RC2/40を使用する必要があります。
Like all algorithms that use 40 bit keys, RC2/40 is considered by many to be weak encryption. A sending agent that is controlled by a human SHOULD allow a human sender to determine the risks of sending data using RC2/40 or a similarly weak encryption algorithm before sending the data, and possibly allow the human to use a stronger encryption method such as tripleDES.
40ビットキーを使用するすべてのアルゴリズムと同様に、RC2/40は多くの人によって弱い暗号化と見なされます。人間によって制御される送信エージェントは、データを送信する前に、人間の送信者がRC2/40または同様に弱い暗号化アルゴリズムを使用してデータを送信するリスクを決定することを可能にする必要があります。。
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 MIME types as well as several CMS content types are used. The data to be secured is always a canonical MIME entity. The MIME entity and other data, such as certificates and algorithm identifiers, are given to CMS processing facilities which produce a CMS object. Finally, the CMS object is wrapped in MIME. The Enhanced Security Services for S/MIME [ESS] document provides descriptions of how nested, secured S/MIME messages are formatted. ESS provides a description of how a triple-wrapped S/MIME message is formatted using multipart/signed and application/pkcs7-mime for the signatures.
このセクションでは、S/MIMEメッセージ形式とそれらの作成方法について説明します。S/MIMEメッセージは、MIMEボディとCMSコンテンツタイプの組み合わせです。いくつかのMIMEタイプといくつかのCMSコンテンツタイプが使用されます。保護されるデータは、常に標準的なmimeエンティティです。証明書やアルゴリズム識別子などのMIMEエンティティやその他のデータは、CMSオブジェクトを生成するCMS処理施設に与えられます。最後に、CMSオブジェクトはMIMEに包まれています。S/MIME [ESS]ドキュメントの強化されたセキュリティサービスは、ネストされたセキュリティされたS/MIMEメッセージのフォーマットの説明を提供します。ESSは、署名のために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は、封筒のみのデータ用の1つの形式、署名のみのデータ用のいくつかの形式、および署名されたデータと包括的なデータ用のいくつかの形式を提供します。特に署名されたメッセージには、いくつかの環境に対応するには、いくつかの形式が必要です。これらの形式から選択するための基準についても説明します。
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 headers and MIME body, and does not include the RFC-822 headers. Note that S/MIME can also be used to secure MIME entities used in applications other than Internet mail. If protection of the RFC-822 headers is required, the use of the message/rfc822 MIME type is explained later in this section.
S/MIMEは、MIMEエンティティを保護するために使用されます。MIMEエンティティは、メッセージのサブパート、サブパート、またはすべてのサブパートを含むメッセージ全体にすることができます。メッセージ全体であるMIMEエンティティには、MIMEヘッダーとMIMEボディのみが含まれ、RFC-822ヘッダーは含まれていません。S/MIMEは、インターネットメール以外のアプリケーションで使用されるMIMEエンティティを保護するためにも使用できることに注意してください。RFC-822ヘッダーの保護が必要な場合、メッセージ/RFC822 MIMEタイプの使用について、このセクションの後半で説明します。
The MIME entity that is secured and described in this section can be thought of as the "inside" MIME entity. That is, it is the "innermost" object in what is possibly a larger MIME message. Processing "outside" MIME entities into CMS content types is described in Section 3.2, 3.4, and elsewhere.
このセクションで保護および説明されている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. Description of the procedures from [MIME-SPEC] are repeated here, but it is suggested that the reader refer to that document for the exact procedure. This section also describes additional requirements.
MIMEエンティティを準備する手順は、[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 headers (for instance, the "Subject", "To", "From" and "CC" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these headers. It is up to the receiving client to decide how to present these "inner" headers along with the unprotected "outer" headers.
外側の非コンテンツ関連のメッセージヘッダー（たとえば、「サブジェクト」、「」、「 "from"、 "fields）を保護するために、送信クライアントはメッセージ/rfc822ラッパーで完全なmimeメッセージをラップすることができます。これらのヘッダーにS/MIMEセキュリティサービスを適用するため。これらの「内側」ヘッダーと保護されていない「外側」ヘッダーを提示する方法を決定するのは、受信クライアント次第です。
When an S/MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822, it can be assumed that the intent was to provide header protection. This entity SHOULD be presented as the top-level message, taking into account header merging issues as previously discussed.
S/MIMEメッセージが受信されると、トップレベルの保護されたMIMEエンティティにメッセージ/RFC822のコンテンツタイプがある場合、ヘッダー保護を提供する意図があると想定できます。このエンティティは、以前に説明したように、ヘッダーのマージの問題を考慮して、トップレベルのメッセージとして提示する必要があります。
Each MIME entity MUST be converted to a canonical form that is uniquely and unambiguously representable in the environment where the signature is created and the environment where the signature will be verified. MIME entities MUST be canonicalized for enveloping and compressing as well as signing.
各MIMEエンティティは、署名が作成されている環境と署名が検証される環境で、独特かつ明確に表現できる標準形式に変換する必要があります。MIMEエンティティは、署名だけでなく包み込みと圧縮のために正規化されなければなりません。
The exact details of canonicalization depend on the actual MIME type and subtype of an entity, and are not described here. Instead, the standard for the particular MIME type SHOULD be consulted. For example, canonicalization of type text/plain is different from canonicalization of audio/basic. Other than text types, most types have only one representation regardless of computing platform or environment which can be considered their canonical representation. In general, canonicalization will be performed by the non-security part of the sending agent rather than the S/MIME implementation.
標準化の正確な詳細は、実際のMIMEタイプとエンティティのサブタイプに依存しますが、ここでは説明されていません。代わりに、特定のMIMEタイプの標準に相談する必要があります。たとえば、タイプテキスト/プレーンの正規化は、音声/基本の正規化とは異なります。テキストタイプ以外に、ほとんどのタイプには、コンピューティングプラットフォームや環境に関係なく、標準表現と見なすことができる表現は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]. The chosen charset SHOULD be named in the charset parameter so that the receiving agent can unambiguously determine the charset used.
最も一般的で重要な標準化はテキスト用であり、これは多くの場合、環境によって異なって表されます。主要なタイプの「テキスト」のMIMEエンティティでは、ラインエンディングと文字セットの両方の標準化されている必要があります。ラインエンディングは文字<cr> <lf>のペアでなければならず、charsetは登録されたcharset [charsets]でなければなりません。標準化の詳細は[MIME-SPEC]で指定されています。受信エージェントが使用されるcharSetを明確に決定できるように、選択したcharsetはcharsetパラメーターに命名する必要があります。
Note that some charsets such as ISO-2022 have multiple representations for the same characters. When preparing such text for signing, the canonical representation specified for the charset MUST be used.
ISO-2022などの一部の充電器には、同じ文字の複数の表現があることに注意してください。署名のためにそのようなテキストを準備する場合、charsetに指定された標準表現を使用する必要があります。
When generating any of the secured MIME entities below, except the signing using the multipart/signed format, no transfer encoding is required at all. S/MIME implementations MUST be able to deal with binary MIME objects. If no Content-Transfer-Encoding header is present, the transfer encoding is presumed to be 7BIT.
MultiPart/Signed Formatを使用した署名を除き、以下の保護されたMIMEエンティティを生成する場合、転送エンコードはまったく必要ありません。S/MIMEの実装は、バイナリMIMEオブジェクトを処理できる必要があります。コンテンツ転送エンコードヘッダーが存在しない場合、転送エンコードは7ビットと推定されます。
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の実装では、セクション3.1.3で説明されているすべてのMIMEエンティティに記載されている転送エンコードを使用する必要があります。輸送にさらされていない包括的なデータであっても、7ビットMIMEエンティティのみを保護する理由は、MIMEエンティティを変更せずにあらゆる環境で処理できるようにするためです。たとえば、信頼できるゲートウェイは、メッセージの署名ではなく封筒を削除してから、署名を直接確認できるように署名されたメッセージを最後の受信者に転送する場合があります。サイト内部のトランスポートが8ビットクリーンではない場合、単一のメールゲートウェイを備えた幅広いエリアネットワークなど、元のMIMEエンティティが7ビットデータのみでない限り、署名が不可能であることを確認します。
S/MIME implementations which "know" that all intended recipient(s) are capable of handling inner (all but the outermost) binary MIME objects SHOULD use binary encoding as opposed to a 7-bit-safe transfer encoding for the inner entities. The use of a 7-bit-safe encoding (such as base64) would unnecessarily expand the message size. Implementations MAY "know" that recipient implementations are capable of handling inner binary MIME entities either by interpreting the id-cap-preferBinaryInside sMIMECapabilities attribute, by prior agreement, or by other means.
意図されたすべての受信者が内部（最も外側を除くすべての）バイナリMIMEオブジェクトを処理できることを「知っている」S/MIME実装では、内部エンティティの7ビット安全性転送エンコードとは対照的に、バイナリエンコードを使用する必要があります。7ビットセーフエンコード（Base64など）を使用すると、メッセージサイズが不必要に拡張されます。実装は、ID-CAP-PreferbinaryInside SmimeCapabilities属性を事前の合意により解釈することにより、または他の手段で、受信者の実装が内部のバイナリMIMEエンティティを処理できることを「知っている」場合があります。
If one or more intended recipients are unable to handle inner binary MIME objects, or if this capability is unknown for any of the intended recipients, S/MIME implementations SHOULD use transfer encoding described in section 3.1.3 for all MIME entities they secure.
1人以上の意図した受信者が内側のバイナリMIMEオブジェクトを処理できない場合、または意図した受信者のいずれかでこの機能が不明な場合、S/MIMEの実装は、それらが確保するすべてのMIMEエンティティのセクション3.1.3で説明した転送エンコードを使用する必要があります。
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.
マルチパート/署名されたエンティティが、標準のインターネットSMTPインフラストラクチャまたは7ビットテキストに制約されているその他のトランスポートを介して送信される場合、7ビットテキストとして表されるように転送エンコードを適用する必要があります。7ビットデータであるMIMEエンティティは、すでに転送エンコードを必要としません。8ビットテキストやバイナリデータなどのエンティティは、引用符で囲まれたものまたはベース64転送エンコードでエンコードできます。
The primary reason for the 7-bit requirement is that the Internet mail transport infrastructure cannot guarantee transport of 8-bit or binary data. Even though many segments of the transport infrastructure now handle 8-bit and even binary data, it is sometimes not possible to know whether the transport path is 8-bit clean. If a mail message with 8-bit data were to encounter a message transfer agent that can not transmit 8-bit or binary data, the agent has three options, none of which are acceptable for a clear-signed message:
7ビット要件の主な理由は、インターネットメールトランスポートインフラストラクチャが8ビットまたはバイナリデータの輸送を保証できないことです。トランスポートインフラストラクチャの多くのセグメントが8ビットおよびバイナリデータを処理するようになりましたが、トランスポートパスが8ビットクリーンであるかどうかを知ることができない場合があります。8ビットデータを含むメールメッセージが8ビットまたはバイナリデータを送信できないメッセージ転送エージェントに遭遇する場合、エージェントには3つのオプションがありますが、どれも明確な署名メッセージに対して受け入れられません。
- The agent could change the transfer encoding; this would invalidate the signature. - The agent could transmit the data anyway, which would most likely result in the 8th bit being corrupted; this too would invalidate the signature. - The agent could return the message to the sender.
- エージェントは転送エンコーディングを変更できます。これにより、署名が無効になります。 - エージェントはとにかくデータを送信することができます。これにより、8番目のビットが破損する可能性が高いでしょう。これも署名を無効にします。 - エージェントは送信者にメッセージを返すことができます。
[MIME-SECURE] prohibits an agent from changing the transfer encoding of the first part of a multipart/signed message. If a compliant agent that can not transmit 8-bit or binary data encounters a multipart/signed message with 8-bit or binary data in the first part, it would have to return the message to the sender as undeliverable.
[Mime-Secure]は、エージェントがマルチパート/署名されたメッセージの最初の部分の転送エンコードを変更することを禁止しています。8ビットまたはバイナリデータを送信できない準拠エージェントが、最初の部分で8ビットまたはバイナリデータを使用してマルチパート/署名されたメッセージに遭遇した場合、有望として送信者にメッセージを返す必要があります。
This example shows a multipart/mixed message with full transfer encoding. This message contains a text part and an attachment. The sample message text includes characters that are not US-ASCII and thus need to be transfer encoded. Though not shown here, the end of each line is <CR><LF>. The line ending of the MIME headers, the text, and transfer encoded parts, all MUST be <CR><LF>.
この例は、完全な転送エンコードを備えたマルチパート/混合メッセージを示しています。このメッセージには、テキストパーツと添付ファイルが含まれています。サンプルメッセージテキストには、us-asciiではないため、エンコードする必要がある文字が含まれています。ここには示されていませんが、各ラインの端は<cr> <lf>です。MIMEヘッダー、テキスト、および転送エンコードされた部品の終わりはすべて<cr> <lf>でなければなりません。
Note that this example is not of an S/MIME message.
この例はS/MIMEメッセージではないことに注意してください。
Content-Type: multipart/mixed; boundary=bar
--bar
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
=A1Hola Michael!
= a1holaマイケル！
How do you like the new S/MIME specification?
新しいS/MIME仕様はどうですか？
It's generally a good idea to encode lines that begin with From=20because some mail transport agents will insert a greater-than (>) sign, thus invalidating the signature.
一部のメールトランスポートエージェントがより大きな（>）サインを挿入して署名を無効にするため、= 20から始まる行をエンコードすることをお勧めします。
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
また、場合によっては、線で発生する= 20の末尾のホワイトスペースをエンコードすることが望ましい場合があります。= 20を通過するときにメッセージの署名が無効にならないことを保証するために、そのような白人を変更するゲートウェイ（Bitnetのように）を変更します。= 20
--bar
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI=
IQVAWUBMJRRF2N9OWBGHPDJAQE9UQQATL7LURVNDBJRK4EQYBIB3H5QXIX/LC // JJV5BNVKZIGPICEMI5IFD9BOEGVPIRHTIREEEQLKLKINOBC3CLKINOBC3CLKINOBCLKINOBCLKINOBC3 i9ig/2yh7lfrk5ein57u/w72vgsxlhe/zhdfolt9brn hoxea44b ei =
--bar--
- バー -
The application/pkcs7-mime type is used to carry CMS content types including EnvelopedData, SignedData, and CompressedData. The details of constructing these entities is described in subsequent sections. This section describes the general characteristics of the application/pkcs7-mime type.
アプリケーション/PKCS7-MIMEタイプは、EnvelopedData、SignedData、CompressedDataなどのCMSコンテンツタイプを運ぶために使用されます。これらのエンティティの構築の詳細は、後続のセクションで説明されています。このセクションでは、アプリケーション/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.
CARRIED CMSオブジェクトには、EcontentTypeがID-DATAの場合、セクション3.1で説明されているように準備されたMIMEエンティティが常に含まれています。EcontentTypeに異なる値が含まれている場合、他のコンテンツを運ぶことができます。署名された領収書を使用したこの例については、[ess]を参照してください。
Since CMS content types are binary data, in most cases base-64 transfer encoding is appropriate, in particular, when used with SMTP transport. The transfer encoding used depends on the transport through which the object is to be sent, and is not a characteristic of the MIME type.
CMSコンテンツタイプはバイナリデータであるため、ほとんどの場合、SMTP輸送で使用する場合、ベース64転送エンコードが適切です。使用される転送エンコーディングは、オブジェクトを送信する輸送に依存し、MIMEタイプの特徴ではありません。
Note that this discussion refers to the transfer encoding of the CMS object or "outside" MIME entity. It is completely distinct from, and unrelated to, the transfer encoding of the MIME entity secured by the CMS object, the "inside" object, which is described in section 3.1.
この議論は、CMSオブジェクトまたは「外部」MIMEエンティティの転送エンコードを指していることに注意してください。セクション3.1で説明されている「内部」オブジェクトで保護されている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 MIME headers of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections.
アプリケーション/PKCS7-MIMEオブジェクトにはいくつかのタイプがあるため、送信エージェントは、受信エージェントがオブジェクトのASN.1をデコードすることなく、受信エージェントがオブジェクトの内容を知るのを助けるためにできるだけ多くのことを行う必要があります。すべてのアプリケーション/PKCS7-MIMEオブジェクトのMIMEヘッダーには、次のセクションで説明されているように、オプションの「SMIMEタイプ」パラメーターを含める必要があります。
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: MIME Type File Extension
アプリケーション/PKCS7-MIMEの場合、送信エージェントは、古いシステムとの互換性のために、オプションの「名前」パラメーターをコンテンツタイプのフィールドに放出する必要があります。送信エージェントは、「Filename」パラメーターを使用して、オプションのコンテンツ配置フィールド[contdisp]を放出する必要があります。送信エージェントが上記のパラメーターを発する場合、パラメーターの値は適切な拡張機能を備えたファイル名である必要があります：MIMEタイプファイル拡張機能
application/pkcs7-mime (SignedData, EnvelopedData) .p7m
Application/PKCS7-MIME（SignedData、EnvelopedData）.P7M
application/pkcs7-mime (degenerate SignedData .p7c certificate management message)
Application/PKCS7-MIME（Degenerate SignedData .P7C証明書管理メッセージ）
application/pkcs7-mime (CompressedData) .p7z
Application/PKCS7-MIME（CompressedData）.P7Z
application/pkcs7-signature (SignedData) .p7s
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文字の拡張機能を使用する必要があります。8文字のファイル名ベースは、任意の名前の名前を付けることができます。ファイル名ベース「SMIME」の使用は、MIMEエンティティがS/MIMEに関連付けられていることを示すために使用する必要があります。
Including a file name serves two purposes. It facilitates easier use of S/MIME objects as files on disk. It also can convey type information across gateways. When a MIME entity of type application/pkcs7-mime (for example) arrives at a gateway that has no special knowledge of S/MIME, it will default the entity's MIME type to application/octet-stream and treat it as a generic attachment, thus losing the type information. However, the suggested filename for an attachment is often carried across a gateway. This often allows the receiving systems to determine the appropriate application to hand the attachment off to, in this case, a stand-alone S/MIME processing application. Note that this mechanism is provided as a convenience for implementations in certain environments. A proper S/MIME implementation MUST use the MIME types and MUST NOT rely on the file extensions.
ファイル名を含むには、2つの目的が提供されます。S/MIMEオブジェクトをディスク上のファイルとして使いやすく使用します。また、ゲートウェイ全体にタイプ情報を伝えることができます。タイプアプリケーション/PKCS7-MIMEのMIMEエンティティ（たとえば）がS/MIMEの特別な知識のないゲートウェイに到着すると、エンティティのMIMEタイプをアプリケーション/オクテットストリームにデフォルトし、一般的な添付ファイルとして扱います。したがって、タイプ情報を失います。ただし、添付ファイルの提案されたファイル名は、多くの場合、ゲートウェイを横切って行われます。これにより、受信システムは適切なアプリケーションを決定して、この場合はスタンドアロンS/MIME処理アプリケーションに添付ファイルを引き渡すことができます。このメカニズムは、特定の環境での実装の便利さとして提供されることに注意してください。適切なS/MIME実装では、MIMEタイプを使用する必要があり、ファイル拡張機能に依存してはなりません。
The application/pkcs7-mime content type defines the optional "smime-type" parameter. The intent of this parameter is to convey details about the security applied (signed or enveloped) along with information about the contained content. This specification defines the following smime-types.
アプリケーション/PKCS7-MIMEコンテンツタイプは、オプションの「SMIMEタイプ」パラメーターを定義します。このパラメーターの意図は、含まれているコンテンツに関する情報とともに、適用されたセキュリティ（署名または封筒）に関する詳細を伝えることです。この仕様は、次のスマイムタイプを定義します。
Name CMS type Inner Content
enveloped-data EnvelopedData id-data
封筒の包まれたdata id-data
signed-data SignedData id-data
certs-only SignedData none
compressed-data CompressedData id-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タイプのパラメーターを割り当てるときに、次のガイドラインに従う必要があります。
1. If both signing and encryption can be applied to the content, then two values for smime-type SHOULD be assigned "signed-*" and "encrypted-*". If one operation can be assigned then this can be omitted. Thus since "certs-only" can only be signed, "signed-" is omitted.
1. 署名と暗号化の両方をコンテンツに適用できる場合、SMIMEタイプの2つの値に「Signed-*」と「暗号化 - *」を割り当てる必要があります。1つの操作を割り当てることができる場合、これは省略できます。したがって、「CERTSのみ」に署名することができるため、「署名」は省略されています。
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の共通文字列を割り当てる必要があります。MIMEが内部コンテンツである場合、ID-DATAコンテンツOIDに「データ」を使用します。
3. If no common string is assigned. Then the common string of "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would be DES40).
3. 一般的な文字列が割り当てられていない場合。次に、「oid。<oid>」の一般的な文字列が推奨されます（たとえば、 "oid.1.3.6.1.1.5.5.7.6.1"はdes40になります）。
It is explicitly intended that this field be a suitable hint for mail client applications to indicate whether a message is "signed" or "encrypted" without having to tunnel into the CMS payload.
このフィールドは、メッセージがCMSペイロードにトンネルを抑えることなく「署名」されるか「暗号化」されているかを示すために、メールクライアントアプリケーションに適したヒントであることを明示的に意図しています。
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エンティティおよびその他の必要なデータは、タイプエンベロープドタのCMSオブジェクトに処理されます。各受信者のコンテンツ暗号化キーのコピーを暗号化することに加えて、コンテンツ暗号化キーのコピーをオリジネーター用に暗号化し、EnvelopedDataに含める必要があります（[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オブジェクトは、アプリケーション/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タイプのパラメーターは、「封筒」です。このタイプのメッセージのファイル拡張子は「.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
rfvbnj756tbbghyhhujhjhjhh77n8hhgt9hg4vqpfyf467ghigfhfyt6 7n8hgghyhhhujhhjh4vqpfyf467ghigfhfhfhfigtrfbnjt6jh7756h756h775h7756hfbb8hfbnjhpbnjt6jh775h775h75h775h775h775h775h775h775h775h775h775h775h775h775h775h775h775h775h775h775h775h75h75h75h775h75h775h75h775h775h75h75h775h75h75h75h75h75hv tbb9hg4vqbnj7567ghigfhfyt6ghyhhuujpfyf4 0ghigfhfqbnj756yt64v
There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents MUST be able to handle both.
s/mime用に定義された署名済みメッセージには2つの形式があります：signeddataを使用したアプリケーション/pkcs7-mimeとmultipart/signed。一般に、MultiPart/署名されたフォームが送信に優先され、受信エージェントが両方を処理できる必要があります。
There are no hard-and-fast rules when a particular signed-only format is chosen because it depends on the capabilities of all the receivers and the relative importance of receivers with S/MIME facilities being able to verify the signature versus the importance of receivers without S/MIME software being able to view the message.
特定の署名済みのみの形式が選択されている場合、ハードとファストのルールはありません。これは、すべての受信機の機能と、S/MIME施設を持つ受信機の相対的な重要性に依存しているため、署名と受信機の重要性を検証できるためです。S/MIMEソフトウェアがメッセージを表示できません。
Messages signed using the multipart/signed format can always be viewed by the receiver whether they have S/MIME software or not. They can also be viewed whether they are using a MIME-native user agent or they have messages translated by a gateway. In this context, "be viewed" means the ability to process the message essentially as if it were not a signed message, including any other MIME structure the message might have.
MultiPart/署名された形式を使用して署名されたメッセージは、s/mimeソフトウェアを持っているかどうかにかかわらず、いつでも受信者が表示できます。また、Mime-Nativeユーザーエージェントを使用しているか、ゲートウェイで翻訳されたメッセージがあるかどうかを確認することもできます。この文脈では、「表示される」とは、メッセージが署名されたメッセージではないかのように、メッセージを本質的に処理する能力を意味します。
Messages signed using the SignedData format cannot be viewed by a recipient unless they have S/MIME facilities. However, the SignedData format protects the message content from being changed by benign intermediate agents. Such agents might do line wrapping or content-transfer encoding changes which would break the signature.
SignedData形式を使用して署名されたメッセージは、S/MIME施設がない限り、受信者が表示することはできません。ただし、SignedData形式は、良性中間エージェントによってメッセージコンテンツが変更されないように保護します。そのようなエージェントは、署名を破る変化をエンコードするラインラッピングまたはコンテンツ転送エンコードを行う可能性があります。
This signing format uses the application/pkcs7-mime MIME type. The steps to create this format are:
この署名形式では、アプリケーション/PKCS7-MIME 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 is processed into a CMS object of type SignedData.
ステップ2. MIMEエンティティおよびその他の必要なデータは、signedDataのタイプのCMSオブジェクトに処理されます。
Step 3. The SignedData object is wrapped in a CMS ContentInfo object.
ステップ3. SignedDataオブジェクトは、CMS ContentINFOオブジェクトに包まれています。
Step 4. The ContentInfo object is inserted into an application/pkcs7-mime MIME entity.
ステップ4. ContentInfoオブジェクトは、アプリケーション/PKCS7-MIME 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タイプパラメーターは「署名されたデータ」です。このタイプのメッセージのファイル拡張子は「.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
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 MIME type described in [MIME-SECURE]. The multipart/signed MIME type has two parts. The first part contains the MIME entity that is signed; the second part contains the "detached signature" CMS SignedData object in which the encapContentInfo eContent field is absent.
この形式は、明確な署名形式です。S/MIMEまたはCMS処理施設のない受信者は、メッセージを表示できます。[mime-secure]で説明されているマルチパート/署名されたmimeタイプを使用します。マルチパート/署名されたMIMEタイプには2つの部分があります。最初の部分には、署名されたMIMEエンティティが含まれています。2番目の部分には、encapContentInfo econtentフィールドが存在しない「デタッチされた署名」CMS SignedDataオブジェクトが含まれています。
This MIME type always contains a CMS ContentInfo containing a single CMS object of type SignedData. The SignedData encapContentInfo eContent field MUST be absent. The signerInfos field contains the signatures for the MIME entity.
このMIMEタイプには、常にsignedDataの単一のCMSオブジェクトを含むCMS contentInfoが含まれています。SignedData EncapContentInfo Econtentフィールドはない必要があります。Signerinfosフィールドには、MIMEエンティティの署名が含まれています。
The file extension for signed-only messages using application/pkcs7- signature is ".p7s".
アプリケーション/PKCS7-署名を使用した署名のみのメッセージのファイル拡張機能は「.p7s」です。
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. MIMEエンティティは、CMS処理に提示され、EncapContentInfo Econtentフィールドが存在しないタイプSignedDataのオブジェクトを取得します。
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に記載されているもの以外の処理なしで、マルチパート/署名されたメッセージの最初の部分に挿入されます。
Step 4. Transfer encoding is applied to the "detached signature" CMS SignedData object and it is inserted into a MIME entity of type application/pkcs7-signature.
ステップ4.転送エンコーディングは、「デタッチされた署名」CMS SignedDataオブジェクトに適用され、タイプアプリケーション/PKCS7シグネチャのMIMEエンティティに挿入されます。
Step 5. The MIME entity of the application/pkcs7-signature is inserted into the second part of the multipart/signed entity.
ステップ5.アプリケーションのMIMEエンティティ/PKCS7-署名は、MultiPart/Signed Entityの第2部に挿入されます。
The multipart/signed Content type has two required parameters: the protocol parameter and the micalg parameter.
MultiPart/署名されたコンテンツタイプには、プロトコルパラメーターと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.
プロトコルパラメーターは「アプリケーション/PKCS7シグネチャ」でなければなりません。MIMEにはパラメーター値の「/」文字を引用する必要があるため、プロトコルパラメーターの周りに引用符が必要であることに注意してください。
The micalg parameter allows for one-pass processing when the signature is being verified. The value of the micalg parameter is dependent on the message digest algorithm(s) used in the calculation of the Message Integrity Check. If multiple message digest algorithms are used they MUST be separated by commas per [MIME-SECURE]. The values to be placed in the micalg parameter SHOULD be from the following: Algorithm Value used
micalgパラメーターは、署名が検証されているときにワンパス処理を可能にします。Micalgパラメーターの値は、メッセージ整合性チェックの計算で使用されるメッセージダイジェストアルゴリズムに依存します。複数のメッセージダイジェストアルゴリズムを使用する場合は、[Mime-Secure]ごとにコンマで分離する必要があります。micalgパラメーターに配置される値は、次のものから次のものでなければなりません：使用されるアルゴリズム値
MD5 md5 SHA-1 sha1 SHA-256 sha256 SHA-384 sha384 SHA-512 sha512 Any other (defined separately in algorithm profile or "unknown" if not defined)
MD5 MD5 SHA-1 SHA1 SHA-256 SHA256 SHA-384 SHA384 SHA-512 SHA512その他（定義されていない場合はアルゴリズムプロファイルまたは「不明」）で個別に定義）
(Historical note: some early implementations of S/MIME emitted and expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize.
（歴史的注：Micalgパラメーターの「RSA-MD5」および「RSA-SHA1」を発し、予想されるS/MIMEの早期実装。
The SHA-256, SHA-384, and SHA-512 algorithms [FIPS180-2] are not currently recommended in S/MIME, and are included here for completeness.
SHA-256、SHA-384、およびSHA-512アルゴリズム[FIPS180-2]は現在、S/MIMEで推奨されておらず、完全性のためにここに含まれています。
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
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
--boundary42--
-boundary42---
The content that is digested (the first part of the multipart/signed) are the bytes:
消化されるコンテンツ（マルチパート/署名の最初の部分）はバイトです。
43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
43 6f 6e 74 65 656e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 69 6e 0d 0a 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 6720 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 3.1 did not specify any use of CompressedData, and will not recognize it. The use of a capability to indicate the ability to receive CompressedData is described in [CMSCOMPR] and is the preferred method for compatibility.
このセクションでは、MIMEエンティティを圧縮するための形式について説明します。3.1より前のS/MIMEのバージョンは、圧縮されたDataの使用を指定しておらず、それを認識しないことに注意してください。圧縮されたDataを受信する能力を示す機能の使用は、[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 is processed into a CMS object of type CompressedData.
ステップ2. MIMEエンティティおよびその他の必要なデータは、CMS CMS Object of Type CompredessDataに処理されます。
Step 3. The CompressedData object is wrapped in a CMS ContentInfo object.
ステップ3.圧縮されたDataオブジェクトは、CMS contentinfoオブジェクトに包まれています。
Step 4. The ContentInfo object is inserted into an application/pkcs7-mime MIME entity.
ステップ4. ContentInfoオブジェクトは、アプリケーション/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タイプのパラメーターは「圧縮データ」です。このタイプのメッセージのファイル拡張子は「.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
rfvbnj756tbbghyhhujhjhjhh77n8hhgt9hg4vqpfyf467ghigfhfyt6 7n8hgghyhhhujhhjh4vqpfyf467ghigfhfhfhfigtrfbnjt6jh7756h756h775h7756hfbb8hfbnjhpbnjt6jh775h775h75h775h775h775h775h775h775h775h775h775h775h775h775h775h775h775h775h775h775h775h75h75h75h775h75h775h75h775h775h75h75h775h75h75h75h75h75hv tbb9hg4vqbnj7567ghigfhfyt6ghyhhuujpfyf4 0ghigfhfqbnj756yt64v
The signed-only, encrypted-only, and compressed-only MIME formats can be nested. This works because these formats are all MIME entities that encapsulate other MIME entities.
署名のみ、暗号化のみ、圧縮のみのMIME形式をネストできます。これらの形式はすべて、他のMIMEエンティティをカプセル化するMIMEエンティティであるため、これは機能します。
An S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME within reasonable resource limits of the recipient computer.
S/MIMEの実装は、受信者コンピューターの合理的なリソース制限内で任意にネストされたS/MIMEを受け取り、処理できる必要があります。
It is possible to apply any of the signing, encrypting, and compressing operations in any order. It is up to the implementer and the user to choose. When signing first, the signatories are then securely obscured by the enveloping. When enveloping first the signatories are exposed, but it is possible to verify signatures without removing the enveloping. This can be useful in an environment were automatic signature verification is desired, as no private key material is required to verify a signature.
任意の順序で署名、暗号化、および圧縮のいずれかを適用することができます。選択するのは実装者とユーザー次第です。最初に署名すると、署名者は包み込みによってしっかりと不明瞭になります。最初に包むとき、署名者は露出していますが、封筒を削除せずに署名を検証することが可能です。これは、署名が必要であるため、自動署名検証が必要な環境で役立つ可能性があります。
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. - If a lossy compression algorithm is used with signing, you will need to compress first, then sign.
- バイナリエンコードされた暗号化されたデータの圧縮は、大きな圧縮が得られないため、推奨されます。ただし、Base64暗号化されたデータは非常に多くの利益をもたらす可能性があります。 - 署名時に損失のある圧縮アルゴリズムが使用されている場合は、最初に圧縮してから署名する必要があります。
The certificate management message or MIME entity is used to transport certificates and/or certificate revocation lists, such as in response to a registration request.
証明書管理メッセージまたはMIMEエンティティは、登録要求に応じて、証明書および/または証明書の取り消しリストを輸送するために使用されます。
Step 1. The certificates and/or certificate revocation lists are made available to the CMS generating process which creates a CMS object of type SignedData. The SignedData encapContentInfo eContent field MUST be absent and signerInfos field MUST be empty.
ステップ1.証明書および/または証明書の取り消しリストは、signedDataのタイプのCMSオブジェクトを作成するCMS生成プロセスで利用可能になります。SignedData EncapContentInfo Econtentフィールドは欠席し、Signerinfosフィールドは空でなければなりません。
Step 2. The SignedData object is wrapped in a CMS ContentInfo object.
ステップ2. SignedDataオブジェクトは、CMS ContentINFOオブジェクトにラップされています。
Step 3. The ContentInfo object is enclosed in an application/pkcs7- mime MIME entity.
ステップ3. ContentInfoオブジェクトは、アプリケーション/PKCS7-MIME MIMEエンティティに囲まれています。
The smime-type parameter for a certificate management message is "certs-only". The file extension for this type of message is ".p7c".
証明書管理メッセージのSMIMEタイプのパラメーターは「CERTSのみ」です。このタイプのメッセージのファイル拡張子は「.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 certificate authority, through a hardware token or diskette, and so on.
メッセージに署名する送信エージェントには、受信エージェントが署名を検証できるように、署名の証明書が必要です。証明書当局との交換、ハードウェアトークンやディスケットなど、証明書を取得する方法はたくさんあります。
S/MIME v2 [SMIMEV2] specified a method for "registering" public keys with certificate authorities using an application/pkcs10 body part. Since that time, the IETF PKIX Working Group has developed other methods for requesting certificates. However, S/MIME v3.1 does not require a particular certificate request mechanism.
S/MIME V2 [SMIMEV2]は、アプリケーション/PKCS10ボディパーツを使用して証明書当局に公開キーを「登録」する方法を指定しました。それ以来、IETF PKIXワーキンググループは、証明書を要求する他の方法を開発してきました。ただし、S/MIME V3.1では、特定の証明書要求メカニズムを必要としません。
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, or the "filename" parameter on the content-disposition header. These parameters that give the file suffix are not listed below as part of the parameter section.
以下の表のファイルの接尾辞は、コンテンツタイプのヘッダーの「名前」パラメーター、またはコンテンツディスポジションヘッダーの「ファイル名」パラメーターからのものです。ファイルの接尾辞を指定するこれらのパラメーターは、パラメーターセクションの一部として以下にリストされていません。
MIME type: application/pkcs7-mime parameters: any file suffix: any
MIMEタイプ：アプリケーション/PKCS7-MIMEパラメーター：任意のファイル接尾辞：任意のファイル
MIME type: multipart/signed
parameters: protocol="application/pkcs7-signature"
file suffix: any
MIME type: application/octet-stream parameters: any file suffix: p7m, p7s, p7c, p7z
MIMEタイプ：アプリケーション/オクテットストリームパラメーター：任意のファイル接尾辞：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 [CERT31].
受信エージェントは、デジタルエンベロープの受信者の証明書にアクセスするために、いくつかの証明書取得メカニズムを提供する必要があります。この仕様では、S/MIMEエージェントが証明書を処理する方法をカバーするものではなく、証明書が検証または拒否された後に行うことのみを対象としています。S/MIME証明書の問題は[CERT31]で説明されています。
At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message. Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval.
少なくとも、最初のS/MIMEの展開の場合、ユーザーエージェントは、署名された返品メッセージで受信者の証明書を要求する意図した受信者に自動的にメッセージを生成できます。また、エージェントを受信および送信する必要は、ユーザーがそのような方法で特派員の証明書を「保存および保護する」ことを可能にして、後の検索を保証するメカニズムを提供する必要があります。
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.
生成されたすべてのキーペアは、非決定的なランダム入力[ランダム]の適切なソースから生成する必要があり、秘密鍵は安全な方法で保護する必要があります。
If an S/MIME agent needs to generate an RSA key pair, then the S/MIME agent or some related administrative utility or function SHOULD generate RSA key pairs using the following guidelines. A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits. A user agent MUST NOT generate RSA key pairs less than 512 bits long. Creating keys longer than 1024 bits can cause some older S/MIME receiving agents to not be able to verify signatures, but gives better security and is therefore valuable. A receiving agent SHOULD be able to verify signatures with keys of any size over 512 bits. Some agents created in the United States have chosen to create 512 bit keys in order to get more advantageous export licenses. However, 512 bit keys are considered by many to be cryptographically insecure. Implementers SHOULD be aware that multiple (active) key pairs can be associated with a single individual. For example, one key pair can be used to support confidentiality, while a different key pair can be used for authentication.
S/MIMEエージェントがRSAキーペアを生成する必要がある場合、S/MIMEエージェントまたは関連する管理ユーティリティまたは関数は、次のガイドラインを使用してRSAキーペアを生成する必要があります。ユーザーエージェントは、768ビットの最小キーサイズでRSAキーペアを生成する必要があります。ユーザーエージェントは、長さ512ビット未満のRSAキーペアを生成してはなりません。1024ビットを長くするキーを作成すると、一部の古いS/MIME受信エージェントが署名を検証できないようにする可能性がありますが、セキュリティを向上させるため、価値があります。受信エージェントは、512ビットを超える任意のサイズのキーで署名を検証できる必要があります。米国で作成された一部のエージェントは、より有利な輸出ライセンスを取得するために、512ビットキーを作成することを選択しています。ただし、512ビットキーは、多くの人が暗号化されていないと考えられています。実装者は、複数の（アクティブな）キーペアを1人の個人に関連付けることができることに注意する必要があります。たとえば、1つのキーペアを使用して機密性をサポートできますが、認証には別のキーペアを使用できます。
40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of tripleDES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents SHOULD inform senders and recipients of the relative cryptographic strength of messages.
40ビット暗号化は、ほとんどの暗号化者によって弱いと見なされます。S/MIMEで弱い暗号化を使用すると、プレーンテキストの送信に関する実際のセキュリティはほとんどありません。ただし、3倍の仕様や、コミュニケーションをとる当事者により強力な暗号化能力を発表する能力など、S/MIMEの他の機能により、送信者は強力な暗号化を使用するメッセージを作成できます。唯一の代替手段が暗号化されていない場合を除き、弱い暗号化を使用することは決して推奨されません。実行可能な場合、送信および受信エージェントは、送信者と受信者にメッセージの相対的な暗号化強度を通知する必要があります。
It is impossible for most software or people to estimate the value of a message. Further, it is impossible for most software or people to estimate the actual cost of decrypting a message that is encrypted with a key of a particular size. Further, it is quite difficult to determine the cost of a failed decryption if a recipient cannot decode a message. Thus, choosing between different key sizes (or choosing whether to just use plaintext) is also impossible. However, decisions based on these criteria are made all the time, and therefore this specification gives a framework for using those estimates in choosing algorithms.
ほとんどのソフトウェアや人々がメッセージの価値を推定することは不可能です。さらに、ほとんどのソフトウェアや人が特定のサイズのキーで暗号化されたメッセージを解読する実際のコストを推定することは不可能です。さらに、受信者がメッセージをデコードできない場合、復号化に失敗したコストを判断することは非常に困難です。したがって、異なるキーサイズを選択する（または、プレーンテキストを使用するだけであるかどうかを選択する）ことも不可能です。ただし、これらの基準に基づいた決定は常に行われるため、この仕様はアルゴリズムを選択する際にそれらの推定値を使用するためのフレームワークを提供します。
If a sending agent is sending the same message using different strengths of cryptography, an attacker watching the communications channel might be able to determine the contents of the strongly-encrypted message by decrypting the weakly-encrypted version. In other words, a sender SHOULD NOT send a copy of a message using weaker cryptography than they would use for the original of the message.
送信エージェントが暗号化の異なる強みを使用して同じメッセージを送信している場合、コミュニケーションチャネルを監視する攻撃者は、弱く暗号化されたバージョンを復号化することにより、強く暗号化されたメッセージの内容を決定できる可能性があります。言い換えれば、送信者は、メッセージのオリジナルに使用するよりも、弱い暗号化を使用してメッセージのコピーを送信してはなりません。
Modification of the ciphertext can go undetected if authentication is not also used, which is the case when sending EnvelopedData without wrapping it in SignedData or enclosing SignedData within it.
認証も使用されていない場合、暗号文の変更は検出されない可能性があります。これは、SignedDataでラップしたり、その中にSignedDataを囲むことなくEnvelopedDataを送信する場合です。
See RFC 3218 [MMA] for more information about thwarting the adaptive chosen ciphertext vulnerability in PKCS #1 Version 1.5 implementations.
RFC 3218 [MMA]を参照してください。PKCS＃1バージョン1.5の実装で、適応選択した暗号文の脆弱性の妨害の詳細については、参照してください。
In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. These methods are described in RFC 2785 [DHSUB].
状況によっては、大規模なプライムPのプライムオーダーサブグループでのdiffie-hellmanキー契約スキームの使用は、「小型グループ」攻撃として知られる特定の攻撃に対して脆弱です。ただし、これらの攻撃を防ぐ方法は存在します。これらの方法は、RFC 2785 [DHSUB]で説明されています。
A. ASN.1 Module
A. ASN.1モジュール
SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax
SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
-- id-aa is the arc with all new authenticated and unauthenticated
-- attributes produced the by 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
}
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 indicates an ability to receive messages
-- with binary encoding inside the CMS wrapper
id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
-- The following list the OIDs to be used with S/MIME V3
- 次のリストs/mime v3で使用するoids
-- Signature Algorithms Not Found in [CMSALG]
--
-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 2}
--
-- Other Signed Attributes
--
-- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5}
-- See [CMS] for a description of how to encode the attribute
-- value.
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
-- (RC2 Key Length (number of bits))
END
終わり
B. References
B.参照
[CERT31] Ramsdell, B., Ed., "S/MIME Version 3.1 Certificate Handling", RFC 3850, July 2004.
[Cert31] Ramsdell、B.、ed。、「S/Mimeバージョン3.1証明書処理」、RFC 3850、2004年7月。
[CHARSETS] Character sets assigned by IANA. See http://www.iana.org/assignments/character-sets
[charsets] ianaによって割り当てられた文字セット。http://www.iana.org/assignments/character-setsを参照してください
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMSAES] Schaad、J。、「暗号化メッセージ構文（CMS）の高度な暗号化標準（AES）暗号化アルゴリズムの使用」、RFC 3565、2003年7月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG] Housley、R。、「暗号化メッセージ構文（CMS）アルゴリズム」、RFC 3370、2002年8月。
[CMSCOMPR] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[CMSCOMPR] Gutmann、P。、「暗号化メッセージ構文（CMS）の圧縮データコンテンツタイプ」、RFC 3274、2002年6月。
[CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[Contdisp] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージのプレゼンテーション情報の伝達：コンテンツ拡散ヘッダーフィールド」、RFC 2183、1997年8月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS] Hoffman、P。、「S/MIMEの強化されたセキュリティサービス」、RFC 2634、1999年6月。
[FIPS180-2] "Secure Hash Signature Standard (SHS)", National Institute of Standards and Technology (NIST). FIPS Publication 180-2.
[FIPS180-2]「Secure Hash Signature Standard（SHS）」、国立標準技術研究所（NIST）。FIPS Publication 180-2。
[MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime-Spec] Freed、N。and N. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
ムーア、K。、「MIME（多目的インターネットメール拡張）パート3：ASSASCII以外のテキストのメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
Freed、N.、Klensin、J。、およびJ. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、BCP 13、RFC 2048、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[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。、およびN. Freed、「Mimeのセキュリティマルチパート：MultiPart/Signed and MultiPart/暗号化」、RFC 1847、1995年10月。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[必須] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
[X.208-88] Ccitt。推奨X.208：抽象的構文表記1（asn.1）の仕様。1988年。
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[X.209-88] Ccitt。推奨X.209：抽象的な構文表記1（asn.1）の基本エンコードルールの仕様。1988年。
[X.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988.
[X.509-88] Ccitt。推奨X.509：ディレクトリ - 認証フレームワーク。1988年。
[DHSUB] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.
[DHSUB] Zuccherato、R。、「S/MIMEのDiffie-Hellman Key Asmaterメソッドに対する「小型」攻撃を回避する方法」、RFC 2785、2000年3月。
[MMA] Rescorla, E., "Preventing the Million Message Attack on Cryptographic Message Syntax", RFC 3218, January 2002.
[MMA] Rescorla、E。、「暗号化メッセージの構文に対する百万メッセージ攻撃の防止」、RFC 3218、2002年1月。
[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バージョン1.5」、RFC 2315、1998年3月。
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[ランダム] Eastlake 3rd、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。
[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[Smimev2] Dusse、S.、Hoffman、P.、Ramsdell、B.、Lundblade、L。、およびL. Repka、「S/Mimeバージョン2メッセージ仕様」、RFC 2311、1998年3月。
C. Acknowledgements
C.謝辞
Many thanks go out to the other authors of the S/MIME Version 2 Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Lundblade and Lisa Repka.
S/Mimeバージョン2メッセージ仕様RFCの他の著者に感謝します：Steve Dusse、Paul Hoffman、Laurence Lundblade、Lisa Repka。
A number of the members of the S/MIME Working Group have also worked very hard and contributed to this document. Any list of people is doomed to omission, and for that I apologize. In alphabetical order, the following people stand out in my mind due to the fact that they made direct contributions to this document.
S/MIMEワーキンググループの多くのメンバーも非常に一生懸命働いており、この文書に貢献しています。人々のリストは省略する運命にあります、そしてそのために私は謝罪します。アルファベット順に、この文書に直接貢献したという事実により、次の人々は私の頭の中で際立っています。
Tony Capel Piers Chivers Dave Crocker Bill Flanigan Peter Gutmann Paul Hoffman Russ Housley William Ottaway John Pawling Jim Schaad
トニー・ケーペル・ピアーズ・チーバー・デイブ・クロッカー・ビル・フラニガン・ピーター・ガットマン・ポール・ホフマン・ラスト・ハウズリー・ウィリアム・オタウェイ・ジョン・ポーリング・ジム・シャード
D. Editor's Address
D.編集者のアドレス
Blake Ramsdell Sendmail, Inc. 704 228th Ave NE #775 Sammamish, WA 98074
Blake Ramsdell Sendmail、Inc。704 228th Ave NE＃775 Sammamish、WA 98074
EMail: blake@sendmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。