[要約] RFC 5751は、S/MIMEバージョン3.2メッセージ仕様に関するドキュメントであり、電子メールのセキュリティと暗号化を向上させるための標準を提供しています。このRFCの目的は、S/MIMEプロトコルの仕様と使用方法を定義し、安全な電子メール通信を実現することです。
Internet Engineering Task Force (IETF) B. Ramsdell
Request for Comments: 5751 Brute Squad Labs
Obsoletes: 3851 S. Turner
Category: Standards Track IECA
ISSN: 2070-1721 January 2010
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
Secure/Multipurposeインターネットメール拡張機能（S/MIME）バージョン3.2メッセージ仕様
Abstract
概要
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851.
このドキュメントでは、Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2を定義しています。S/MIMEは、安全なMIMEデータを送信および受信するための一貫した方法を提供します。デジタル署名は、認証、メッセージの整合性、および繰り返しの証明を伴う非繰り返しを提供します。暗号化はデータの機密性を提供します。圧縮は、データサイズを削減するために使用できます。このドキュメントは、RFC 3851を廃止します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5751.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5751で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Specification Overview .....................................4
1.2. Definitions ................................................5
1.3. Conventions Used in This Document ..........................6
1.4. Compatibility with Prior Practice of S/MIME ................7
1.5. Changes from S/MIME v3 to S/MIME v3.1 ......................7
1.6. Changes since S/MIME v3.1 ..................................7
2. CMS Options .....................................................9
2.1. DigestAlgorithmIdentifier ..................................9
2.2. SignatureAlgorithmIdentifier ...............................9
2.3. KeyEncryptionAlgorithmIdentifier ..........................10
2.4. General Syntax ............................................11
2.5. Attributes and the SignerInfo Type ........................12
2.6. SignerIdentifier SignerInfo Type ..........................16
2.7. ContentEncryptionAlgorithmIdentifier ......................16
3. Creating S/MIME Messages .......................................18
3.1. Preparing the MIME Entity for Signing, Enveloping,
or Compressing ............................................19
3.2. The application/pkcs7-mime Media Type .....................23
3.3. Creating an Enveloped-Only Message ........................25
3.4. Creating a Signed-Only Message ............................26
3.5. Creating a Compressed-Only Message ........................30
3.6. Multiple Operations .......................................30
3.7. Creating a Certificate Management Message .................31
3.8. Registration Requests .....................................32
3.9. Identifying an S/MIME Message .............................32
4. Certificate Processing .........................................32
4.1. Key Pair Generation .......................................33
4.2. Signature Generation ......................................33
4.3. Signature Verification ....................................34
4.4. Encryption ................................................34
4.5. Decryption ................................................34
5. IANA Considerations ............................................34
5.1. Media Type for application/pkcs7-mime .....................34
5.2. Media Type for application/pkcs7-signature ................35
6. Security Considerations ........................................36
7. References .....................................................38
7.1. Reference Conventions .....................................38
7.2. Normative References ......................................39
7.3. Informative References ....................................41
Appendix A. ASN.1 Module ..........................................43
Appendix B. Moving S/MIME v2 Message Specification to Historic
Status ................................................45
Appendix C. Acknowledgments .......................................45
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures), and data confidentiality (using encryption). As a supplementary service, S/MIME provides for message compression.
S/MIME（Secure/Multipurpose Internet Mail拡張機能）は、安全なMIMEデータを送信および受信するための一貫した方法を提供します。人気のあるインターネットMIME標準に基づいて、S/MIMEは、電子メッセージングアプリケーションの次の暗号化セキュリティサービスを提供します：認証、メッセージの整合性、原産地の非repudiation（デジタル署名を使用）、およびデータの機密性（暗号化を使用）。補足サービスとして、S/MIMEはメッセージ圧縮を提供します。
S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP or SIP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems.
S/MIMEは、従来のメールユーザーエージェント（MUAS）で使用されて、送信されるメールに暗号化セキュリティサービスを追加し、受信したメールで暗号化セキュリティサービスを解釈することができます。ただし、S/MIMEはメールに限定されていません。HTTPやSIPなどの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 of Internet messages and allows extensions for new content-type-based applications.
このドキュメントでは、MIMEデータに暗号化署名および暗号化サービスを追加するためのプロトコルについて説明します。MIME標準[MIME-SPEC]は、インターネットメッセージのコンテンツの一般的な構造を提供し、新しいコンテンツタイプベースのアプリケーションの拡張機能を可能にします。
This specification defines how to create a MIME body part that has been cryptographically enhanced according to the Cryptographic Message Syntax (CMS) RFC 5652 [CMS], which is derived from PKCS #7 [PKCS-7]. This specification also defines the application/pkcs7-mime media type that can be used to transport those body parts.
この仕様では、PKCS＃7 [PKCS-7]に由来する暗号化メッセージ構文（CMS）RFC 5652 [CMS]に従って暗号化されたマイムボディパーツを作成する方法を定義します。この仕様は、それらの身体部分の輸送に使用できるアプリケーション/PKCS7-MIMEメディアタイプも定義します。
This document also discusses how to use the multipart/signed media type defined in [MIME-SECURE] to transport S/MIME signed messages. multipart/signed is used in conjunction with the application/pkcs7- signature media type, which is used to transport a detached S/MIME signature.
このドキュメントでは、[MIME-Secure]で定義されたMultiPart/署名されたメディアタイプを使用して、S/MIME署名されたメッセージを輸送する方法についても説明します。MultiPart/Signedは、アプリケーション/PKCS7-シグネチャーメディアタイプと組み合わせて使用されます。
In order to create S/MIME messages, an S/MIME agent MUST follow the specifications in this document, as well as the specifications listed in the Cryptographic Message Syntax document [CMS], [CMSALG], [RSAPSS], [RSAOAEP], and [CMS-SHA2].
S/MIMEメッセージを作成するには、S/MIMEエージェントがこのドキュメントの仕様と、暗号化メッセージSyntax Document [CMS]、[CMSALG]、[RSAPSS]、[RSAOAEP]にリストされている仕様に従う必要があります。および[CMS-Sha2]。
Throughout this specification, there are requirements and recommendations made for how receiving agents handle incoming messages. There are separate requirements and recommendations for how sending agents create outgoing messages. In general, the best strategy is to "be liberal in what you receive and conservative in what you send". Most of the requirements are placed on the handling of incoming messages, while the recommendations are mostly on the creation of outgoing messages.
この仕様を通して、受信エージェントが着信メッセージを処理する方法について作成された要件と推奨事項があります。エージェントを送信する方法については、発信メッセージを作成する方法については、個別の要件と推奨事項があります。一般的に、最良の戦略は、「あなたが受け取るものでリベラルになり、あなたが送るものに保守的になる」ことです。要件のほとんどは、着信メッセージの処理に配置されていますが、推奨事項は主に発信メッセージの作成にあります。
The separation for requirements on receiving agents and sending agents also derives from the likelihood that there will be S/MIME systems that involve software other than traditional Internet mail clients. S/MIME can be used with any system that transports MIME data. An automated process that sends an encrypted message might not be able to receive an encrypted message at all, for example. Thus, the requirements and recommendations for the two types of agents are listed separately when appropriate.
受信エージェントと送信エージェントの要件の分離は、従来のインターネットメールクライアント以外のソフトウェアを含むS/MIMEシステムが存在する可能性からも派生しています。S/MIMEは、MIMEデータを輸送する任意のシステムで使用できます。暗号化されたメッセージを送信する自動化されたプロセスでは、たとえば、暗号化されたメッセージをまったく受信できない場合があります。したがって、2種類のエージェントの要件と推奨事項は、必要に応じて個別にリストされます。
For the purposes of this specification, the following definitions apply.
この仕様の目的のために、次の定義が適用されます。
ASN.1: Abstract Syntax Notation One, as defined in ITU-T Recommendation X.680 [X.680].
ASN.1：ITU-T推奨x.680 [x.680]で定義されている要約構文表記1。
BER: Basic Encoding Rules for ASN.1, as defined in ITU-T Recommendation X.690 [X.690].
BER：ITU-T推奨x.690 [x.690]で定義されている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 ITU-T Recommendation X.690 [X.690].
der：ITU-T推奨x.690 [x.690]で定義されているように、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エージェント：受信エージェント、送信エージェント、またはその両方であるユーザーソフトウェア。
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月」、および「オプション」は、[必須]で説明されているように解釈される。
We define some additional terms here:
ここでは、いくつかの追加の用語を定義します。
SHOULD+ This term means the same as SHOULD. However, the authors expect that a requirement marked as SHOULD+ will be promoted at some future time to be a MUST.
この用語が必要なものと同じことを意味する場合。ただし、著者は、将来の時間にマークされた要件が必須であるために促進されることを期待しています。
SHOULD- This term means the same as SHOULD. However, the authors expect that a requirement marked as SHOULD- will be demoted to a MAY in a future version of this document.
必要なのは、この用語と同じことと同じことを意味します。ただし、著者は、このドキュメントの将来のバージョンで5月に降格される要件が必要になると予想しています。
MUST- This term means the same as MUST. However, the authors expect that this requirement will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST-requirement, it will remain at least a SHOULD or a SHOULD-.
必須 - この用語は、必須と同じを意味します。ただし、著者らは、将来の文書では、この要件がもはや必須ではないと予想しています。そのステータスは後で決定されますが、ドキュメントの将来の改訂が必須の状況を変える場合、少なくとも必要または必要なもののままであることを期待するのが合理的です。
S/MIME version 3.2 agents ought to attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive and RFC 5035 [SMIMEv3], and S/MIME version 3.1 is described in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1]. RFC 2311 also has historical information about the development of S/MIME.
S/MIMEバージョン3.2エージェントは、S/MIMEの以前のバージョンのエージェントと可能な限り最大の相互運用性を持つことを試みる必要があります。S/MIMEバージョン2は、RFC 2311からRFC 2315インクルーシブ[SMIMEV2]、S/MIMEバージョン3でRFC 2630からRFC 2634 InclusiveおよびRFC 5035 [SMIMEV3]、およびS/MIMEバージョン3.1で、RFC 3850で説明されています。、RFC 3851、RFC 3852、RFC 2634、およびRFC 5035 [SMIMEV3.1]。RFC 2311には、S/MIMEの開発に関する歴史的情報もあります。
The RSA public key algorithm was changed to a MUST implement key wrapping algorithm, and the Diffie-Hellman (DH) algorithm changed to a SHOULD implement.
RSAの公開キーアルゴリズムは、a必要のあるキーラッピングアルゴリズムに変更され、diffie-hellman（dh）アルゴリズムが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 media type has been added.
メッセージ/RFC822メディアタイプの使用によるヘッダー保護が追加されました。
Use of the CompressedData CMS type is allowed, along with required media type and file extension additions.
必要なメディアタイプとファイル拡張機能の追加とともに、圧縮されたData CMSタイプの使用が許可されています。
Editorial changes, e.g., replaced "MIME type" with "media type", content-type with Content-Type.
たとえば、編集上の変更は、「MIMEタイプ」を「メディアタイプ」に置き換え、コンテンツタイプのコンテンツタイプに置き換えます。
Moved "Conventions Used in This Document" to Section 1.3. Added definitions for SHOULD+, SHOULD-, and MUST-.
「このドキュメントで使用されている規則」をセクション1.3に移動しました。必要なもの、必要、および必須の定義を追加しました。
Section 1.1 and Appendix A: Added references to RFCs for RSASSA-PSS, RSAES-OAEP, and SHA2 CMS algorithms. Added CMS Multiple Signers Clarification to CMS reference.
セクション1.1および付録A：RSASSA-PSS、RSAES-OAEP、およびSHA2 CMSアルゴリズムのRFCSへの参照を追加しました。CMS複数の署名者がCMSリファレンスに明確化を追加しました。
Section 1.2: Updated references to ASN.1 to X.680 and BER and DER to X.690.
セクション1.2：asn.1からx.680への参照、およびberおよびderへの参照をx.690に更新しました。
Section 1.4: Added references to S/MIME MSG 3.1 RFCs.
セクション1.4：S/MIME MSG 3.1 RFCへの参照を追加しました。
Section 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5 made SHOULD-.
セクション2.1（ダイジェストアルゴリズム）：sha-256が必要に応じて追加され、sha-1とmd5はdecd-を作成しました。
Section 2.2 (signature algorithms): RSA with SHA-256 added as MUST, and DSA with SHA-256 added as SHOULD+, RSA with SHA-1, DSA with SHA-1, and RSA with MD5 changed to SHOULD-, and RSASSA-PSS with SHA-256 added as SHOULD+. Also added note about what S/MIME v3.1 clients support.
セクション2.2（署名アルゴリズム）：SHA-256を使用したRSAは必須で追加され、SHA-256を使用したDSAは、SHA-1を使用したRSA、SHA-1を含むDSA、MD5を使用したRSAがSufdに変更され、RSasasa-SHA-256を備えたPSSが追加されたように追加されました。また、S/MIME V3.1クライアントがサポートするものについてのメモも追加されました。
Section 2.3 (key encryption): DH changed to SHOULD-, and RSAES-OAEP added as SHOULD+. Elaborated requirements for key wrap algorithm.
セクション2.3（キー暗号化）：DHはdechに変更され、RSAES-OAEPが必要に応じて追加されました。キーラップアルゴリズムの詳細な要件。
Section 2.5.1: Added requirement that receiving agents MUST support both GeneralizedTime and UTCTime.
セクション2.5.1：受信エージェントが一般化された時間とUTCTIMEの両方をサポートする必要があるという要件を追加しました。
Section 2.5.2: Replaced reference "sha1WithRSAEncryption" with "sha256WithRSAEncryption", "DES-3EDE-CBC" with "AES-128 CBC", and deleted the RC5 example.
セクション2.5.2：参照「sha1withrsaencryption」を「sha256withrsaencryption」、「des-3ede-cbc」に「AES-128 CBC」に置き換え、RC5の例を削除しました。
Section 2.5.2.1: Deleted entire section (discussed deprecated RC2).
セクション2.5.2.1：セクション全体を削除しました（非推奨RC2について説明しました）。
Section 2.7, 2.7.1, Appendix A: references to RC2/40 removed.
セクション2.7、2.7.1、付録A：RC2/40への参照削除。
Section 2.7 (content encryption): AES-128 CBC added as MUST, AES-192 and AES-256 CBC SHOULD+, tripleDES now SHOULD-.
セクション2.7（コンテンツ暗号化）：AES-128 CBCは、AES-192およびAES-256 CBCが必要になっているように追加されました。
Section 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to 2.7.1.1 to 2.7.1.2.
セクション2.7.1：2.7.2.1から2.7.2.4から2.7.1.1〜2.7.1.2からポインターを更新しました。
Section 3.1.1: Removed text about MIME character sets.
セクション3.1.1：MIMEキャラクターセットに関するテキストを削除しました。
Section 3.2.2 and 3.6: Replaced "encrypted" with "enveloped". Update OID example to use AES-128 CBC oid.
セクション3.2.2および3.6：「暗号化された」を「封筒」に置き換えました。oidの例を更新して、AES-128 CBC OIDを使用します。
Section 3.4.3.2: Replace micalg parameter for SHA-1 with sha-1.
セクション3.4.3.2：SHA-1のMicalgパラメーターをSHA-1に置き換えます。
Section 4: Updated reference to CERT v3.2.
セクション4：CERT V3.2への参照を更新しました。
Section 4.1: Updated RSA and DSA key size discussion. Moved last four sentences to security considerations. Updated reference to randomness requirements for security.
セクション4.1：RSAおよびDSAキーサイズのディスカッションを更新しました。最後の4文をセキュリティ上の考慮事項に移動しました。セキュリティのランダム性要件への参照を更新しました。
Section 5: Added IANA registration templates to update media type registry to point to this document as opposed to RFC 2311.
セクション5：IANA登録テンプレートを追加して、RFC 2311とは対照的に、このドキュメントを指すメディアタイプレジストリを更新しました。
Section 6: Updated security considerations.
セクション6：セキュリティ上の考慮事項を更新しました。
Section 7: Moved references from Appendix B to this section. Updated references. Added informational references to SMIMEv2, SMIMEv3, and SMIMEv3.1.
セクション7：付録Bからこのセクションに参照を移動しました。更新された参照。SMIMEV2、SMIMEV3、およびSMIMEV3.1への情報参照を追加しました。
Appendix B: Added Appendix B to move S/MIME v2 to Historic status.
付録B：付録Bを追加して、S/MIME V2を歴史的なステータスに移動します。
CMS allows for a wide variety of options in content, attributes, and algorithm support. This section puts forth a number of support requirements and recommendations in order to achieve a base level of interoperability among all S/MIME implementations. [CMSALG] and [CMS-SHA2] provides additional details regarding the use of the cryptographic algorithms. [ESS] provides additional details regarding the use of additional attributes.
CMSは、コンテンツ、属性、およびアルゴリズムのサポートにさまざまなオプションを可能にします。このセクションでは、すべてのS/MIME実装の間で相互運用性の基本レベルを達成するために、多くのサポート要件と推奨事項を示します。[CMSALG]および[CMS-Sha2]は、暗号化アルゴリズムの使用に関する追加の詳細を提供します。[ESS]は、追加の属性の使用に関する追加の詳細を提供します。
Sending and receiving agents MUST support SHA-256 [CMS-SHA2] and SHOULD- support SHA-1 [CMSALG]. Receiving agents SHOULD- support MD5 [CMSALG] for the purpose of providing backward compatibility with MD5-digested S/MIME v2 SignedData objects.
送信および受信エージェントは、SHA-256 [CMS-SHA2]をサポートし、SHA-1 [CMSAlg]をサポートする必要があります。受信エージェントは、MD5デザインのS/MIME V2 SignedDataオブジェクトとの後方互換性を提供する目的で、MD5 [CMSALG]をサポートする必要があります。
Receiving agents:
受信エージェント：
- MUST support RSA with SHA-256.
- SHA-256でRSAをサポートする必要があります。
- SHOULD+ support DSA with SHA-256.
- SHA-256でDSAをサポートする必要があります。
- SHOULD+ support RSASSA-PSS with SHA-256.
- SHA-256でRSASSA-PSSをサポートする必要があります。
- SHOULD- support RSA with SHA-1.
- SHA-1でRSAをサポートする必要があります。
- SHOULD- support DSA with SHA-1.
- SHA-1でDSAをサポートする必要があります。
- SHOULD- support RSA with MD5.
- MD5でRSAをサポートする必要があります。
Sending agents:
送信エージェント：
- MUST support RSA with SHA-256.
- SHA-256でRSAをサポートする必要があります。
- SHOULD+ support DSA with SHA-256.
- SHA-256でDSAをサポートする必要があります。
- SHOULD+ support RSASSA-PSS with SHA-256.
- SHA-256でRSASSA-PSSをサポートする必要があります。
- SHOULD- support RSA with SHA-1 or DSA with SHA-1.
- SHA-1でRSAまたはSHA-1でDSAをサポートする必要があります。
- SHOULD- support RSA with MD5.
- MD5でRSAをサポートする必要があります。
See Section 4.1 for information on key size and algorithm references.
キーサイズとアルゴリズムの参照については、セクション4.1を参照してください。
Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and rsaEncryption and might not implement sha256withRSAEncryption. Note that S/MIME v3 clients might only implement signing or signature verification using id-dsa-with-sha1, and might also use id-dsa as an AlgorithmIdentifier in this field. Receiving clients SHOULD recognize id-dsa as equivalent to id-dsa-with-sha1, and sending clients MUST use id-dsa-with-sha1 if using that algorithm. Also note that S/MIME v2 clients are only required to verify digital signatures using the rsaEncryption algorithm with SHA-1 or MD5, and might not implement id-dsa-with-sha1 or id-dsa at all.
S/MIME v3.1クライアントは、id-dsa-with-sha1およびrsaencryptionの検証をサポートしており、sha256withrsaencryptionを実装しない可能性があることに注意してください。S/MIME V3クライアントは、ID-DSA-With-Sha1を使用してSINGILIFICIFITIONのみを実装する場合があり、このフィールドの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を実装しない場合があることに注意してください。
Receiving and sending agents:
エージェントの受信と送信：
- MUST support RSA Encryption, as specified in [CMSALG].
- [cmsalg]で指定されているように、RSA暗号化をサポートする必要があります。
- SHOULD+ support RSAES-OAEP, as specified in [RSAOAEP].
- [rsaoaep]で指定されているように、RSAES-OAEPをサポートする必要があります。
- SHOULD- support DH ephemeral-static mode, as specified in [CMSALG] and [SP800-57].
- [CMSAlg]および[SP800-57]で指定されているように、DH Ephemeral-Static Modeをサポートする必要があります。
When DH ephemeral-static is used, a key wrap algorithm is also specified in the KeyEncryptionAlgorithmIdentifier [CMS]. The underlying encryption functions for the key wrap and content encryption algorithm ([CMSALG] and [CMSAES]) and the key sizes for the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm with AES-128 content encryption algorithm). As AES-128 CBC is the mandatory-to-implement content encryption algorithm, the AES-128 key wrap algorithm MUST also be supported when DH ephemeral-static is used.
DH EPHEMERAL-STATICを使用すると、KeyEncryptionAlgorithMidentifier [CMS]でキーラップアルゴリズムも指定されています。キーラップおよびコンテンツ暗号化アルゴリズム（[cmsalg]および[cmsaes]）の基礎となる暗号化と、2つのアルゴリズムのキーサイズは同じでなければなりません（たとえば、AES-128コンテンツのコンテンツ暗号化アルゴリズムを備えたAES-128キーラップアルゴリズム）。AES-128 CBCは必須のコンテンツ暗号化アルゴリズムであるため、DH Ephemeral-Staticを使用する場合、AES-128キーラップアルゴリズムもサポートする必要があります。
Note that S/MIME v3.1 clients might only implement key encryption and decryption using the rsaEncryption algorithm. Note that S/MIME v3 clients might only implement key encryption and decryption using the Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only capable of decrypting content-encryption keys using the rsaEncryption algorithm.
S/MIME V3.1クライアントは、RSAENCryptionアルゴリズムを使用してキー暗号化と復号化のみを実装できることに注意してください。S/MIME V3クライアントは、Diffie-Hellmanアルゴリズムを使用してキー暗号化と復号化のみを実装できることに注意してください。また、S/MIME V2クライアントは、RSAENCRyptionアルゴリズムを使用してコンテンツ暗号化キーを復号化できることにのみ注意してください。
There are several CMS content types. Of these, only the Data, SignedData, EnvelopedData, and CompressedData content types are currently used for S/MIME.
いくつかのCMSコンテンツタイプがあります。これらのうち、現在S/MIMEには、データ、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 media type MUST be stored in the SignedData encapContentInfo eContent OCTET STRING (unless the sending agent is using multipart/signed, in which case the eContent is absent, per Section 3.4.3 of this document). As another example, when applying encryption to MIME data, the CMS EnvelopedData encryptedContentInfo contentType MUST include the id-data object identifier and the encrypted MIME content MUST be stored in the EnvelopedData encryptedContentInfo encryptedContent OCTET STRING.
送信エージェントは、ID-DATAコンテンツタイプ識別子を使用して、「内側の」MIMEメッセージコンテンツを識別する必要があります。たとえば、デジタル署名をMIMEデータに適用する場合、CMS SignedData EncapContentInfo EcontentTypeにはID-DATAオブジェクト識別子を含める必要があり、メディアタイプはSignedData EncapContentInfo Econtent Octet文字列に保存する必要があります（送信中のエージェントがMultiPart/Signedを使用しない限り、この場合、このドキュメントのセクション3.4.3に従って、econtentが存在しません）。別の例として、MIMEデータに暗号化を適用する場合、CMS EnvelopedData暗号化されたContentInfo contentTypeを含める必要があり、暗号化されたMIMEコンテンツは、封筒EncryptedContentInfo EncryptedContent Octet Stringに保存する必要があります。
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 the message's size.
このコンテンツタイプは、メッセージにデータ圧縮を適用するために使用されます。このコンテンツタイプは、認証、メッセージの整合性、非繰り返し、またはデータの機密性を提供するものではなく、メッセージのサイズを縮小するためにのみ使用されます。
See Section 3.6 for further guidance on the use of this type in conjunction with other CMS types.
他のCMSタイプと組み合わせて、このタイプの使用に関するさらなるガイダンスについては、セクション3.6を参照してください。
The SignerInfo type allows the inclusion of unsigned and signed attributes along with a signature.
SignerINFOタイプにより、署名と署名の属性と署名属性を含めることができます。
Receiving agents MUST be able to handle zero or one instance of each of the signed attributes listed here. Sending agents SHOULD generate one instance of each of the following signed attributes in each S/MIME message:
受信エージェントは、ここにリストされている各署名属性のゼロまたは1つのインスタンスを処理できる必要があります。送信エージェントは、各s/mimeメッセージに次の各署名属性の1つのインスタンスを生成する必要があります。
- Signing Time (section (Section 2.5.1 in this document)
- 署名時間（このドキュメントのセクション2.5.1）
- SMIME Capabilities (section (Section 2.5.2 in this document)
- スマイム機能（セクション2.5.2このドキュメントのセクション2.5.2）
- Encryption Key Preference (section (Section 2.5.3 in this document)
- 暗号化のキー設定（セクション2.5.3このドキュメントのセクション2.5.3）
- Message Digest (section (Section 11.2 in [CMS])
- メッセージダイジェスト（セクション11.2 in [cms]）
- Content Type (section (Section 11.1 in [CMS])
- コンテンツタイプ（[CMS]のセクション11.1）
Further, receiving agents SHOULD be able to handle zero or one instance of the signingCertificate and signingCertificatev2 signed attributes, as defined in Section 5 of RFC 2634 [ESS] and Section 3 of RFC 5035 [ESS].
さらに、受信エージェントは、RFC 2634のセクション5 [ESS]およびRFC 5035 [ESS]のセクション3で定義されているように、signingCertificateおよびSigniveCertificatev2の署名属性のゼロまたは1つのインスタンスを処理できる必要があります。
Sending agents SHOULD generate one instance of the signingCertificate or signingCertificatev2 signed attribute in each SignerInfo structure.
送信エージェントは、各SignerInfo構造でsigningCertificateまたはsigningCertificatev2の署名属性の1つのインスタンスを生成する必要があります。
Additional attributes and values for these attributes might be defined in the future. Receiving agents SHOULD handle attributes or values that they do not recognize in a graceful manner.
これらの属性の追加の属性と値は、将来定義される場合があります。受信エージェントは、優雅な方法で認識していない属性または値を処理する必要があります。
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と解釈されます。
Receiving agents MUST be able to process signing-time attributes that are encoded in either UTCTime or GeneralizedTime.
受信エージェントは、UTCTIMEまたはGeneralizedTimeでエンコードされる署名時間属性を処理できる必要があります。
The SMIMECapabilities attribute includes signature algorithms (such as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128 CBC"), and key encipherment algorithms (such as "rsaEncryption"). There are also several identifiers that indicate support for other optional features such as binary encoding and compression. The SMIMECapabilities were designed to be flexible and extensible so that, in the future, a means of identifying other capabilities and preferences such as certificates can be added in a way that will not cause current clients to break.
SmimeCapabilities属性には、署名アルゴリズム（「SHA256WithRSAENCRYPTION」など）、対称アルゴリズム（「AES-128 CBC」など）、およびキーエンカーメントアルゴリズム（「rsaencryption」など）が含まれます。また、バイナリエンコードや圧縮など、他のオプション機能のサポートを示すいくつかの識別子もあります。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属性はSigneDattributeでなければなりません。署名されていないものであってはなりません。CMSは、SigneDattributesを一連の属性として定義します。SignerInfoのSigneDattributesには、SmimeCapabilities属性の複数のインスタンスを含めてはなりません。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 AES-128 CBC MUST be identically encoded regardless of the implementation. Because of the requirement for identical encoding, individuals documenting algorithms to be used in the SMIMECapabilities attribute SHOULD explicitly document the correct byte sequence for the common cases.
SmimeCapability属性の構造は、一致を決定するために、単純なテーブルの検索とバイナリ比較を促進することです。たとえば、AES-128 CBCのSmimecapabilityのderエンコードは、実装に関係なく同一にエンコードする必要があります。同一のエンコーディングの要件があるため、SmimeCapabilities属性で使用されるアルゴリズムを文書化する個人は、共通の場合の正しいバイトシーケンスを明示的に文書化する必要があります。
For any capability, the associated parameters for the OID MUST specify all of the parameters necessary to differentiate between two instances of the same algorithm.
任意の機能については、OIDの関連するパラメーターは、同じアルゴリズムの2つのインスタンスを区別するために必要なすべてのパラメーターを指定する必要があります。
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. 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 Listは、それらを必要とするOIDのパラメーター、特に可変長対称暗号の場合の重要な長さを指定します。特定のOIDに差別化されたパラメーターがない場合、パラメーターを省略する必要があり、nullとしてエンコードしてはなりません。SmimeCapability属性の追加値は、将来定義される可能性があります。受信エージェントは、優雅な方法で認識されない値を持つSmimeCapabilitiesオブジェクトを処理する必要があります。
Section 2.7.1 explains a strategy for caching capabilities.
セクション2.7.1では、キャッシュ機能の戦略について説明します。
The encryption key preference attribute allows the signer to unambiguously describe which of the signer's certificates has the signer's preferred encryption key. This attribute is designed to enhance behavior for interoperating with those clients that use separate keys for encryption and signing. This attribute is used to convey to anyone viewing the attribute which of the listed certificates is appropriate for encrypting a session key for future encrypted messages.
暗号化キー設定属性により、署名者は署名者の証明書のどれが署名者の優先暗号化キーを持っているかを明確に説明できます。この属性は、暗号化と署名に個別のキーを使用するクライアントとの相互運用の動作を強化するように設計されています。この属性は、属性を表示する人に伝達されるために使用されます。これは、将来の暗号化されたメッセージのセッションキーを暗号化するのに適しています。
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には、SmimeCryptionKeypreference属性の複数のインスタンスを含めてはなりません。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.
受信エージェントは、メッセージの署名が有効であり、署名時間が現在保存されている値よりも大きい場合は、優先データを保存する必要があります。（SmimeCapabilityと同様に、クロックスキューをチェックする必要があり、スキューが大きすぎる場合はデータを使用しないでください。）受信エージェントは、可能であれば、送信者の暗号化キー設定属性を尊重する必要があります。ただし、これは優先権のみを表し、受信エージェントは有効な送信者に返信する際に任意の証明書を使用できます。
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.
- SMIMECRYCTINGKEYPREFERCENT属性が、目的の受信者から受信した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 signer of a X.509 certificate that can be used for key management.
- smimecryctrantkeypreference属性が目的の受信者から受信した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.2 implementations MUST support both issuerAndSerialNumber and subjectKeyIdentifier. Messages that use the subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
S/MIME v3.2実装は、発行者と件名の両方のidentientifierの両方をサポートする必要があります。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 AES-128 CBC [CMSAES].
- AES-128 CBC [CMSAES]で暗号化と復号化をサポートする必要があります。
- SHOULD+ support encryption and decryption with AES-192 CBC and AES-256 CBC [CMSAES].
- AES-192 CBCおよびAES-256 CBC [CMSAES]による暗号化と復号化をサポートする必要があります。
- SHOULD- support encryption and decryption with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG].
- DES EDE3 CBCによる暗号化と復号化をサポートする必要があります。
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. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use.
メッセージを送信する前に、送信エージェントは、メッセージ内の特定のデータに弱い暗号化を使用する意思があるかどうかを決定する必要があります。送信エージェントがこのデータに対して弱い暗号化が受け入れられないと判断した場合、送信エージェントは弱いアルゴリズムを使用してはなりません。弱い暗号化を使用または使用しないという決定は、このセクションで使用する暗号化アルゴリズムについて他の決定を上書きします。
Sections 2.7.1.1 through 2.7.1.2 describe the decisions a sending agent SHOULD use in deciding which type of encryption will be applied to a message. These rules are ordered, so the sending agent SHOULD make its decision in the order given.
セクション2.7.1.1から2.7.1.2は、送信エージェントがメッセージに適用される暗号化のタイプを決定する際に使用すべき決定について説明します。これらのルールは順序付けられているため、送信エージェントは与えられた順序で決定を下す必要があります。
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:
次の2つの条件が満たされている場合：
- the sending agent has no knowledge of the encryption capabilities of the recipient, and
- 送信エージェントには、受信者の暗号化機能に関する知識がありません。
- the sending agent has no knowledge of the version of S/MIME of the recipient,
- 送信エージェントには、受信者のS/MIMEのバージョンに関する知識がありません。
then the sending agent SHOULD use AES-128 because it is a stronger algorithm and is required by S/MIME v3.2. If the sending agent chooses not to use AES-128 in this step, it SHOULD use tripleDES.
次に、送信エージェントはAES-128を使用する必要があります。これは、より強力なアルゴリズムであり、S/MIME V3.2で必要であるためです。送信エージェントがこのステップでAES-128を使用しないことを選択した場合、3倍を使用する必要があります。
All algorithms that use 40-bit keys are considered by many to be weak encryption. A sending agent that is controlled by a human SHOULD allow a human sender to determine the risks of sending data using a weak encryption algorithm before sending the data, and possibly allow the human to use a stronger encryption method such as tripleDES or AES.
40ビットキーを使用するすべてのアルゴリズムは、多くの人によって弱い暗号化と見なされます。人間によって制御される送信エージェントは、データを送信する前に弱い暗号化アルゴリズムを使用してデータを送信するリスクを決定することを可能にする必要があります。
If a sending agent is composing an encrypted message to a group of recipients where the encryption capabilities of some of the recipients do not overlap, the sending agent is forced to send more than one message. Please note that if the sending agent chooses to send a message encrypted with a strong algorithm, and then send the same message encrypted with a weak algorithm, someone watching the communications channel could learn the contents of the strongly encrypted message simply by decrypting the weakly encrypted message.
送信エージェントが、一部の受信者の暗号化機能が重複しない受信者のグループに暗号化されたメッセージを作成している場合、送信エージェントは複数のメッセージを送信することを余儀なくされます。送信エージェントが強力なアルゴリズムで暗号化されたメッセージを送信することを選択し、その後、弱いアルゴリズムで暗号化された同じメッセージを送信する場合、コミュニケーションチャネルを見る人は、弱い暗号化された暗号化を解体するだけで強く暗号化されたメッセージの内容を学ぶことができることに注意してください。メッセージ。
This section describes the S/MIME message formats and how they are created. S/MIME messages are a combination of MIME bodies and CMS content types. Several media types as well as several CMS content types are used. The data to be secured is always a canonical MIME entity. The MIME entity and other data, such as certificates and algorithm identifiers, are given to CMS processing facilities that produce a CMS object. Finally, the CMS object is wrapped in MIME. The Enhanced Security Services for S/MIME [ESS] document provides descriptions of how nested, secured S/MIME messages are formatted. ESS provides a description of how a triple-wrapped S/MIME message is formatted using multipart/signed and application/pkcs7-mime for the signatures.
このセクションでは、S/MIMEメッセージ形式とそれらの作成方法について説明します。S/MIMEメッセージは、MIMEボディとCMSコンテンツタイプの組み合わせです。いくつかのメディアタイプといくつかのCMSコンテンツタイプが使用されます。保護されるデータは、常に標準的なmimeエンティティです。証明書やアルゴリズム識別子などのMIMEエンティティやその他のデータは、CMSオブジェクトを生産するCMS処理施設に与えられます。最後に、CMSオブジェクトはMIMEに包まれています。S/MIME [ESS]ドキュメントの強化されたセキュリティサービスは、ネストされたセキュリティされたS/MIMEメッセージのフォーマットの説明を提供します。ESSは、署名に対してマルチパート/署名とアプリケーション/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 message headers and MIME body, and does not include the RFC-822 header. Note that S/MIME can also be used to secure MIME entities used in applications other than Internet mail. If protection of the RFC-822 header is required, the use of the message/rfc822 media type is explained later in this section.
S/MIMEは、MIMEエンティティを保護するために使用されます。MIMEエンティティは、メッセージのサブパート、サブパート、またはすべてのサブパートを含むメッセージ全体にすることができます。メッセージ全体であるMIMEエンティティには、MIMEメッセージヘッダーとMIMEボディのみが含まれており、RFC-822ヘッダーは含まれていません。S/MIMEは、インターネットメール以外のアプリケーションで使用されるMIMEエンティティを保護するためにも使用できることに注意してください。RFC-822ヘッダーの保護が必要な場合、メッセージ/RFC822メディアタイプの使用について、このセクションで後で説明します。
The MIME entity that is secured and described in this section can be thought of as the "inside" MIME entity. That is, it is the "innermost" object in what is possibly a larger MIME message. Processing "outside" MIME entities into CMS content types is described in Sections 3.2, 3.4, and elsewhere.
このセクションで保護および説明されているMIMEエンティティは、「内部」MIMEエンティティと考えることができます。つまり、それはおそらくより大きなmimeメッセージである「最も内側の」オブジェクトです。「外部」MIMEエンティティをCMSコンテンツタイプに処理することは、セクション3.2、3.4などで説明されています。
The procedure for preparing a MIME entity is given in [MIME-SPEC]. The same procedure is used here with some additional restrictions when signing. The description of the procedures from [MIME-SPEC] is repeated here, but it is suggested that the reader refer to that document for the exact procedure. This section also describes additional requirements.
MIMEエンティティを準備する手順は、[MIME-SPEC]で提供されます。ここでは、署名時にいくつかの追加の制限があり、ここでも同じ手順が使用されます。[MIME-SPEC]からの手順の説明はここで繰り返されますが、読者は正確な手順についてそのドキュメントを参照することをお勧めします。このセクションでは、追加の要件についても説明します。
A single procedure is used for creating MIME entities that are to have any combination of signing, enveloping, and compressing applied. Some additional steps are recommended to defend against known corruptions that can occur during mail transport that are of particular importance for clear-signing using the multipart/signed format. It is recommended that these additional steps be performed on enveloped messages, or signed and enveloped messages, so that the message can be forwarded to any environment without modification.
署名、封筒、および圧縮の任意の組み合わせを備えたMIMEエンティティの作成には、単一の手順が使用されます。MultiPart/Signed形式を使用して明確な署名にとって特に重要な郵便輸送中に発生する可能性のある既知の腐敗を防御するために、いくつかの追加の手順が推奨されます。これらの追加の手順は、包み込まれたメッセージ、または署名されたメッセージと包括的なメッセージで実行することをお勧めします。これにより、メッセージは変更なしで任意の環境に転送できます。
These steps are descriptive rather than prescriptive. The implementer is free to use any procedure as long as the result is the same.
これらの手順は、規範的ではなく説明的です。実装者は、結果が同じである限り、あらゆる手順を自由に使用できます。
Step 1. The MIME entity is prepared according to the local conventions.
ステップ1. MIMEエンティティは、地元の条約に従って準備されています。
Step 2. The leaf parts of the MIME entity are converted to canonical form.
ステップ2. MIMEエンティティの葉の部分は、標準形式に変換されます。
Step 3. Appropriate transfer encoding is applied to the leaves of the MIME entity.
ステップ3.適切な転送エンコードは、MIMEエンティティの葉に適用されます。
When an S/MIME message is received, the security services on the message are processed, and the result is the MIME entity. That MIME entity is typically passed to a MIME-capable user agent where it is further decoded and presented to the user or receiving application.
S/MIMEメッセージが受信されると、メッセージのセキュリティサービスが処理され、結果はMIMEエンティティになります。そのMIMEエンティティは通常、MIME対応のユーザーエージェントに渡され、さらにデコードされ、ユーザーまたは受信アプリケーションに提示されます。
In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these header fields. It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header.
外側の非コンテンツ関連のメッセージヘッダーフィールド（たとえば、「件名」、「to」、「from」、「cc」フィールド）を保護するために、送信クライアントはメッセージに完全なmimeメッセージを包むことができます/RFC822ラッパーこれらのヘッダーフィールドに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 media type and subtype of an entity, and are not described here. Instead, the standard for the particular media type SHOULD be consulted. For example, canonicalization of type text/plain is different from canonicalization of audio/basic. Other than text types, most types have only one representation regardless of computing platform or environment that can be considered their canonical representation. In general, canonicalization will be performed by the non-security part of the sending agent rather than the S/MIME implementation.
標準化の正確な詳細は、実際のメディアタイプとエンティティのサブタイプに依存し、ここでは説明しません。代わりに、特定のメディアタイプの標準に相談する必要があります。たとえば、タイプテキスト/プレーンの正規化は、音声/基本の正規化とは異なります。テキストタイプ以外には、ほとんどのタイプには、標準表現と見なすことができるコンピューティングプラットフォームや環境に関係なく、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].
最も一般的で重要な標準化はテキスト用であり、これは多くの場合、環境によって異なって表されます。主要なタイプの「テキスト」のMIMEエンティティでは、ラインエンディングと文字セットの両方の標準化されている必要があります。ラインエンディングは文字<cr> <lf>のペアでなければならず、charsetは登録されたcharset [charsets]でなければなりません。標準化の詳細は[MIME-SPEC]で指定されています。
Note that some charsets such as ISO-2022 have multiple representations for the same characters. When preparing such text for signing, the canonical representation specified for the charset MUST be used.
ISO-2022などの一部の充電器には、同じ文字の複数の表現があることに注意してください。署名のためにそのようなテキストを準備する場合、charsetに指定された標準表現を使用する必要があります。
When generating any of the secured MIME entities below, except the signing using the multipart/signed format, no transfer encoding is required at all. S/MIME implementations MUST be able to deal with binary MIME objects. If no Content-Transfer-Encoding header field is present, the transfer encoding is presumed to be 7BIT.
MultiPart/Signed 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 that "know" that all intended recipients are capable of handling inner (all but the outermost) binary MIME objects SHOULD use binary encoding as opposed to a 7-bit-safe transfer encoding for the inner entities. The use of a 7-bit-safe encoding (such as base64) would unnecessarily expand the message size. Implementations MAY "know" that recipient implementations are capable of handling inner binary MIME entities either by interpreting the id-cap-preferBinaryInside SMIMECapabilities attribute, by prior agreement, or by other means.
意図されたすべての受信者が内部（最も外側を除くすべての）バイナリMIMEオブジェクトを処理できることを「知っている」S/MIME実装は、内部エンティティの7ビット安全性転送エンコードとは対照的に、バイナリエンコードを使用する必要があります。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 cannot transmit 8-bit or binary data, the agent has three options, none of which are acceptable for a clear-signed message:
7ビット要件の主な理由は、インターネットメールトランスポートインフラストラクチャが8ビットまたはバイナリデータの輸送を保証できないことです。輸送インフラストラクチャの多くのセグメントが8ビットおよびバイナリデータを処理するようになりましたが、輸送パスが8ビットクリーンであるかどうかを知ることができない場合があります。8ビットデータを含むメールメッセージが8ビットまたはバイナリデータを送信できないメッセージ転送エージェントに遭遇する場合、エージェントには3つのオプションがありますが、どれもクリア署名メッセージには許容されません。
- The agent could change the transfer encoding; this would invalidate the signature.
- エージェントは転送エンコーディングを変更できます。これにより、署名が無効になります。
- The agent could transmit the data anyway, which would most likely result in the 8th bit being corrupted; this too would invalidate the signature.
- とにかくエージェントはデータを送信することができます。これにより、8番目のビットが破損する可能性が最も高くなります。これも署名を無効にします。
- The agent could return the message to the sender.
- エージェントはメッセージを送信者に返すことができます。
[MIME-SECURE] prohibits an agent from changing the transfer encoding of the first part of a multipart/signed message. If a compliant agent that cannot transmit 8-bit or binary data encounters a multipart/signed message with 8-bit or binary data in the first part, it would have to return the message to the sender as undeliverable.
[Mime-Secure]は、エージェントがマルチパート/署名されたメッセージの最初の部分の転送エンコードを変更することを禁止しています。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 the 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を通過するときにメッセージ署名が無効にならないことを保証するために、そのような白人を変更するゲートウェイ（ビットネットなど）を確認します。= 20
--bar
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI=
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b EI=
--bar--
- バー -
The application/pkcs7-mime media type is used to carry CMS content types including EnvelopedData, SignedData, and CompressedData. The details of constructing these entities are described in subsequent sections. This section describes the general characteristics of the application/pkcs7-mime media type.
Application/PKCS7-MIMEメディアタイプは、EnvelopedData、SignedData、CompressedDataなどのCMSコンテンツタイプを運ぶために使用されます。これらのエンティティの構築の詳細は、後続のセクションで説明されています。このセクションでは、アプリケーション/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 media type.
CMSコンテンツタイプはバイナリデータであるため、ほとんどの場合、SMTP輸送で使用する場合、ベース64転送エンコードが適切です。使用される転送エンコーディングは、オブジェクトを送信するトランスポートに依存し、メディアタイプの特性ではありません。
Note that this discussion refers to the transfer encoding of the CMS object or "outside" MIME entity. It is completely distinct from, and unrelated to, the transfer encoding of the MIME entity secured by the CMS object, the "inside" object, which is described in Section 3.1.
この議論は、CMSオブジェクトまたは「外部」MIMEエンティティの転送エンコードを指していることに注意してください。セクション3.1で説明されている「内側」オブジェクトによって保護されたMIMEエンティティの転送エンコードとは完全に異なり、そのままです。
Because there are several types of application/pkcs7-mime objects, a sending agent SHOULD do as much as possible to help a receiving agent know about the contents of the object without forcing the receiving agent to decode the ASN.1 for the object. The Content-Type header field of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections.
アプリケーション/PKCS7-MIMEオブジェクトにはいくつかのタイプがあるため、送信エージェントは、受信エージェントがオブジェクトのASN.1をデコードすることなく、受信エージェントがオブジェクトの内容について知るのを助けるためにできるだけ多くのことを行う必要があります。すべてのアプリケーション/PKCS7-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:
アプリケーション/PKCS7-MIMEの場合、送信エージェントは、古いシステムとの互換性のために、オプションの「名前」パラメーターをコンテンツタイプのフィールドに放出する必要があります。送信エージェントは、「Filename」パラメーターを使用して、オプションのコンテンツ配置フィールド[contdisp]を放出する必要があります。送信エージェントが上記のパラメーターを発した場合、パラメーターの値は適切な拡張機能を備えたファイル名である必要があります。
Media Type File Extension application/pkcs7-mime (SignedData, EnvelopedData) .p7m application/pkcs7-mime (degenerate SignedData .p7c certificate management message) application/pkcs7-mime (CompressedData) .p7z application/pkcs7-signature (SignedData) .p7s
メディアタイプファイル拡張アプリケーション/PKCS7-MIME（SignedData、EnvelopedData）。
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 media type to application/octet-stream and treat it as a generic attachment, thus losing the type information. However, the suggested filename for an attachment is often carried across a gateway. This often allows the receiving systems to determine the appropriate application to hand the attachment off to, in this case, a stand-alone S/MIME processing application. Note that this mechanism is provided as a convenience for implementations in certain environments. A proper S/MIME implementation MUST use the media types and MUST NOT rely on the file extensions.
ファイル名を含めると、2つの目的が提供されます。S/MIMEオブジェクトをディスク上のファイルとして使いやすく使用します。また、ゲートウェイ全体でタイプ情報を伝えることができます。タイプアプリケーション/PKCS7-MIMEのMIMEエンティティ（たとえば）がS/MIMEの特別な知識のないゲートウェイに到着すると、エンティティのメディアタイプをアプリケーション/オクテットストリームにデフォルトし、一般的な添付ファイルとして扱います。したがって、タイプ情報を失います。ただし、添付ファイルの提案されたファイル名は、多くの場合、ゲートウェイを横切って行われます。これにより、受信システムが適切なアプリケーションを決定して、この場合はスタンドアロンS/MIME処理アプリケーションに添付ファイルを引き渡すことができます。このメカニズムは、特定の環境での実装の利便性として提供されていることに注意してください。適切なS/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
signed-data SignedData id-data
certs-only SignedData none
compressed-data CompressedData id-data
In order for consistency to be obtained with future specifications, the following guidelines SHOULD be followed when assigning a new smime-type parameter.
将来の仕様で一貫性を取得するには、新しいSMIMEタイプのパラメーターを割り当てるときに、次のガイドラインに従う必要があります。
1. If both signing and encryption can be applied to the content, then two values for smime-type SHOULD be assigned "signed-*" and "enveloped-*". If one operation can be assigned, then this can be omitted. Thus, since "certs-only" can only be signed, "signed-" is omitted.
1. 署名と暗号化の両方をコンテンツに適用できる場合、SMIMEタイプの2つの値に「Signed-*」と「Enveloped-*」を割り当てる必要があります。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.2.16.840.1.101.3.4.1.2" would be AES-128 CBC).
3. 一般的な文字列が割り当てられていない場合、「oid。<oid>」の共通文字列が推奨されます（たとえば、 "oid.2.16.840.1.101.3.4.1.2"はAES-128 CBCです）。
It is explicitly intended that this field be a suitable hint for mail client applications to indicate whether a message is "signed" or "enveloped" without having to tunnel into the CMS payload.
このフィールドは、メッセージがCMSペイロードにトンネルを抑えることなく「署名」されているか「包まれている」かを示すために、メールクライアントアプリケーションに適したヒントであることを明示的に意図しています。
This section describes the format for enveloping a MIME entity without signing it. It is important to note that sending enveloped but not signed messages does not provide for data integrity. It is possible to replace ciphertext in such a way that the processed message will still be valid, but the meaning can be altered.
このセクションでは、署名せずにMimeエンティティを包む形式について説明します。包み込まれているが署名されていないメッセージを送信しても、データの整合性を提供しないことに注意することが重要です。処理されたメッセージが依然として有効であるように暗号文を交換することは可能ですが、意味を変更することができます。
Step 1. The MIME entity to be enveloped is prepared according to Section 3.1.
ステップ1.包み込むMIMEエンティティは、セクション3.1に従って準備されています。
Step 2. The MIME entity and other required data is processed into a CMS object of type EnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content-encryption key SHOULD be encrypted for the originator and included in the EnvelopedData (see [CMS], Section 6).
ステップ2. MIMEエンティティおよびその他の必要なデータは、タイプエンベロープドダタの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
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V
There are two formats for signed messages defined for S/MIME:
s/mime用に定義された署名されたメッセージの2つの形式があります。
- application/pkcs7-mime with SignedData.
- signeddataを使用したアプリケーション/pkcs7-mime。
- multipart/signed.
- マルチパート/署名。
In general, the multipart/signed form is preferred for sending, and receiving agents MUST be able to handle both.
一般に、MultiPart/署名されたフォームが送信に優先され、受信エージェントが両方を処理できる必要があります。
There are no hard-and-fast rules as to when a particular signed-only format is chosen. It depends on the capabilities of all the receivers and the relative importance of receivers with S/MIME facilities being able to verify the signature versus the importance of receivers without S/MIME software being able to view the message.
特定の署名のみの形式がいつ選択されるかについては、厳しいルールはありません。これは、すべての受信機の機能と、S/MIME機能を使用してレシーバーの相対的な重要性に依存します。S/MIMEソフトウェアがメッセージを表示できない場合、受信機の重要性を検証できます。
Messages signed using the multipart/signed format can always be viewed by the receiver whether or not they have S/MIME software. They can also be viewed whether they are using a MIME-native user agent or they have messages translated by a gateway. In this context, "be viewed" means the ability to process the message essentially as if it were not a signed message, including any other MIME structure the message might have.
MultiPart/署名された形式を使用して署名されたメッセージは、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 that would break the signature.
SignedData形式を使用して署名されたメッセージは、S/MIME機能がない限り、受信者が表示することはできません。ただし、SignedData形式は、良性中間エージェントによってメッセージコンテンツが変更されないように保護します。そのようなエージェントは、署名を破る変化をエンコードするラインラップまたはコンテンツ転送エンコードを行う可能性があります。
This signing format uses the application/pkcs7-mime media type. The steps to create this format are:
この署名形式では、アプリケーション/PKCS7-MIMEメディアタイプを使用します。この形式を作成する手順は次のとおりです。
Step 1. The MIME entity is prepared according to Section 3.1.
ステップ1. MIMEエンティティは、セクション3.1に従って準備されています。
Step 2. The MIME entity and other required data are processed into a CMS object of type SignedData.
ステップ2. MIMEエンティティおよびその他の必要なデータは、signedDataのタイプのCMSオブジェクトに処理されます。
Step 3. The SignedData object is wrapped in a CMS ContentInfo object.
ステップ3. SignedDataオブジェクトは、CMS ContentINFOオブジェクトに包まれています。
Step 4. The ContentInfo object is inserted into an application/pkcs7-mime MIME entity.
ステップ4. contentinfoオブジェクトは、アプリケーション/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 media type described in [MIME-SECURE]. The multipart/signed media type has two parts. The first part contains the MIME entity that is signed; the second part contains the "detached signature" CMS SignedData object in which the encapContentInfo eContent field is absent.
この形式は、明確な署名形式です。S/MIMEまたはCMS処理施設のない受信者は、メッセージを表示できます。[mime-secure]で説明されているマルチパート/署名されたメディアタイプを使用します。MultiPart/署名されたメディアタイプには2つの部分があります。最初の部分には、署名されたMIMEエンティティが含まれています。2番目の部分には、encapContentInfo econtentフィールドが存在しない「デタッチされた署名」CMS SignedDataオブジェクトが含まれています。
This media type always contains a CMS ContentInfo containing a single CMS object of type SignedData. The SignedData encapContentInfo eContent field MUST be absent. The signerInfos field contains the signatures for the MIME entity.
このメディアタイプには、常にsignedDataのタイプの単一のCMSオブジェクトを含む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.アプリケーション/PKCS7-署名のMIMEエンティティは、MultiPart/Signed Entityの第2部に挿入されます。
The multipart/signed Content-Type has two required parameters: the protocol parameter and the micalg parameter.
MultiPart/Signed Content-Typeには、プロトコルパラメーターと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:
micalgパラメーターは、署名が検証されているときにワンパス処理を可能にします。micalgパラメーターの値は、メッセージ整合性チェックの計算で使用されるメッセージダイジェストアルゴリズムに依存します。複数のメッセージダイジェストアルゴリズムを使用する場合、[Mime-Secure]ごとにコンマで分離する必要があります。micalgパラメーターに配置される値は、次のものでなければなりません。
Algorithm Value Used
使用されるアルゴリズム値
MD5 md5 SHA-1 sha-1 SHA-224 sha-224 SHA-256 sha-256 SHA-384 sha-384 SHA-512 sha-512 Any other (defined separately in algorithm profile or "unknown" if not defined)
MD5 MD5 SHA-1 SHA-1 SHA-224 SHA-224 SHA-256 SHA-256 SHA-384 SHA-384 SHA-512 SHA-512その他（定義されていない場合はアルゴリズムプロファイルまたは「不明」で個別に定義）
(Historical note: some early implementations of S/MIME emitted and expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.) Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize. Future names for this parameter will be consistent with the IANA "Hash Function Textual Names" registry.
（歴史的注：s/mimeのいくつかの早期実装は、「rsa-md5」、「rsa-sha1」、および「sha1」を放出および予想したMicalgパラメーターの「Sha1」です。）受信剤は、micalgパラメーター値から優雅に回復できるはずです。彼らは認識しません。このパラメーターの将来の名前は、IANA「ハッシュ関数テキスト名」レジストリと一致します。
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) consists of the bytes:
消化されるコンテンツ（マルチパート/署名の最初の部分）は、バイトで構成されています。
43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
43 6f 6e 74 65 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 6e 0d 0a 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 67 67 65 64 6420 6d 65 73 73 61 67 65 2e 0d 0a
This section describes the format for compressing a MIME entity. Please note that versions of S/MIME prior to version 3.1 did not specify any use of CompressedData, and will not recognize it. The use of a capability to indicate the ability to receive CompressedData is described in [CMSCOMPR] and is the preferred method for compatibility.
このセクションでは、MIMEエンティティを圧縮するための形式について説明します。バージョン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 are processed into a CMS object of type CompressedData.
ステップ2. MIMEエンティティおよびその他の必要なデータは、型圧縮されたタイプのCMSオブジェクトに処理されます。
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
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V
The signed-only, enveloped-only, and compressed-only MIME formats can be nested. This works because these formats are all MIME entities that encapsulate other MIME entities.
署名のみのみ、包み込まれた、および圧縮のみのMIME形式をネストできます。これらの形式はすべて、他のMIMEエンティティをカプセル化するMIMEエンティティであるため、これは機能します。
An S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME within reasonable resource limits of the recipient computer.
S/MIMEの実装は、受信者コンピューターの合理的なリソース制限内でarbitrarily意的にネストされた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 where automatic signature verification is desired, as no private key material is required to verify a signature.
任意の順序で署名、暗号化、および圧縮のいずれかを適用することができます。選択するのは実装者とユーザー次第です。最初に署名すると、署名者は包み込みによってしっかりと不明瞭になります。最初に包むとき、署名者は露出していますが、封筒を削除せずに署名を検証することができます。これは、署名を検証するために秘密のキー資料が必要ないため、自動署名検証が必要な環境で役立ちます。
There are security ramifications to choosing whether to sign first or encrypt first. A recipient of a message that is encrypted and then signed can validate that the encrypted block was unaltered, but cannot determine any relationship between the signer and the unencrypted contents of the message. A recipient of a message that is signed then encrypted can assume that the signed message itself has not been altered, but that a careful attacker could have changed the unauthenticated portions of the encrypted message.
最初に署名するか暗号化するかを選択するためのセキュリティの影響があります。暗号化されてから署名されたメッセージの受信者は、暗号化されたブロックが変更されていないことを検証できますが、署名者とメッセージの暗号化されていない内容との関係を決定することはできません。署名されたメッセージの受信者、その後暗号化されたメッセージは、署名されたメッセージ自体が変更されていないが、慎重な攻撃者が暗号化されたメッセージの認可されていない部分を変更した可能性があると仮定することができます。
When using compression, keep the following guidelines in mind:
圧縮を使用する場合は、次のガイドラインを念頭に置いてください。
- Compression of binary encoded encrypted data is discouraged, since it will not yield significant compression. Base64 encrypted data could very well benefit, however.
- バイナリエンコードされた暗号化されたデータの圧縮は、大きな圧縮が得られないため、推奨されます。ただし、Base64暗号化されたデータは非常に多くの利益をもたらす可能性があります。
- If a lossy compression algorithm is used with signing, you will need to compress first, then sign.
- 署名時に損失のある圧縮アルゴリズムが使用されている場合は、最初に圧縮してから署名する必要があります。
The certificate management message or MIME entity is used to transport certificates and/or Certificate Revocation Lists, such as in response to a registration request.
証明書管理メッセージまたはMIMEエンティティは、登録要求に応じて、証明書および/または証明書の取り消しリストを輸送するために使用されます。
Step 1. The certificates and/or Certificate Revocation Lists are made available to the CMS generating process that creates a CMS object of type SignedData. The SignedData encapContentInfo eContent field MUST be absent and signerInfos field MUST be empty.
ステップ1.証明書および/または証明書の取り消しリストは、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 certification 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.2 does not require a particular certificate request mechanism.
S/MIME V2 [SMIMEV2]は、アプリケーション/PKCS10ボディパーツを使用して証明書当局に公開キーを「登録」する方法を指定しました。それ以来、IETF PKIXワーキンググループは、証明書を要求する他の方法を開発してきました。ただし、S/MIME V3.2では、特定の証明書要求メカニズムを必要としません。
Because S/MIME takes into account interoperation in non-MIME environments, several different mechanisms are employed to carry the type information, and it becomes a bit difficult to identify S/MIME messages. The following table lists criteria for determining whether or not a message is an S/MIME message. A message is considered an S/MIME message if it matches any of the criteria listed below.
S/MIMEは非MIME環境での相互運用を考慮しているため、タイプ情報を運ぶためにいくつかの異なるメカニズムが採用されており、S/MIMEメッセージを識別することが少し難しくなります。次の表には、メッセージがS/MIMEメッセージであるかどうかを判断するための基準を示します。メッセージは、以下にリストされている基準のいずれかに一致する場合、S/MIMEメッセージと見なされます。
The file suffix in the table below comes from the "name" parameter in the Content-Type header field, or the "filename" parameter on the Content-Disposition header field. These parameters that give the file suffix are not listed below as part of the parameter section.
以下の表のファイルの接尾辞は、コンテンツタイプのヘッダーフィールドの「名前」パラメーター、またはコンテンツディスポジションヘッダーフィールドの「ファイル名」パラメーターからのものです。ファイルの接尾辞を指定するこれらのパラメーターは、パラメーターセクションの一部として以下にリストされていません。
Media type: application/pkcs7-mime parameters: any file suffix: any
メディアタイプ：アプリケーション/PKCS7-MIMEパラメーター：任意のファイル接尾辞：任意のファイル
Media type: multipart/signed
parameters: protocol="application/pkcs7-signature"
file suffix: any
Media type: application/octet-stream parameters: any file suffix: p7m, p7s, p7c, p7z
メディアタイプ：アプリケーション/オクテットストリームパラメーター：任意のファイル接尾辞：P7M、P7S、P7C、P7Z
A receiving agent MUST provide some certificate retrieval mechanism in order to gain access to certificates for recipients of digital envelopes. This specification does not cover how S/MIME agents handle certificates, only what they do after a certificate has been validated or rejected. S/MIME certificate issues are covered in [CERT32].
受信エージェントは、デジタルエンベロープの受信者の証明書にアクセスするために、いくつかの証明書取得メカニズムを提供する必要があります。この仕様では、S/MIMEエージェントが証明書を処理する方法をカバーするものではなく、証明書が検証または拒否された後に行うことのみを対象としています。S/MIME証明書の問題は[CERT32]で説明されています。
At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message. Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval.
少なくとも、最初のS/MIMEの展開の場合、ユーザーエージェントは、署名された返品メッセージで受信者の証明書を要求する意図した受信者に自動的にメッセージを生成できます。また、エージェントを受信および送信する必要は、ユーザーがそのような方法で特派員の証明書を「保存および保護」できるように、後の検索を保証するメカニズムを提供する必要があります。
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.
生成されたすべてのキーペアは、非決定的なランダム入力[ランダム]の適切なソースから生成する必要があり、秘密鍵は安全な方法で保護する必要があります。
An S/MIME user agent MUST NOT generate asymmetric keys less than 512 bits for use with the RSA or DSA signature algorithms.
S/MIMEユーザーエージェントは、RSAまたはDSA署名アルゴリズムで使用するために512ビット未満の非対称キーを生成してはなりません。
For 512-bit RSA with SHA-1 see [CMSALG] and [FIPS186-2] without Change Notice 1, for 512-bit RSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] without Change Notice 1, and for 1024-bit through 2048-bit RSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] with Change Notice 1. The first reference provides the signature algorithm's object identifier, and the second provides the signature algorithm's definition.
SHA-1を備えた512ビットRSAについては、[CMSALG]および[FIPS186-2]を変更通知なしに参照してください。SHA-256を使用した2048ビットRSAまでの1024ビットについては、[CMS-SHA2]および[FIPS186-2]を参照してください。
For 512-bit DSA with SHA-1 see [CMSALG] and [FIPS186-2] without Change Notice 1, for 512-bit DSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see [CMSALG] and [FIPS186-2] with Change Notice 1, for 1024-bit and above DSA with SHA-256 see [CMS-SHA2] and [FIPS186-3]. The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition.
SHA-1を備えた512ビットDSAについては、変更通知なしに[cmsalg]および[fips186-2]を参照してください。SHA-1を備えた1024ビットDSAについては、[CMSALG]および[FIPS186-2]を参照してください。1024ビットおよびSHA-256を使用してDSAを超えて[CMS-Sha2]および[FIPS186-3]を参照してください。最初の参照は、署名アルゴリズムのオブジェクト識別子を提供し、2番目は署名アルゴリズムの定義を提供します。
For RSASSA-PSS with SHA-256, see [RSAPSS]. For 1024-bit DH, see [CMSALG]. For 1024-bit and larger DH, see [SP800-56A]; regardless, use the KDF, which is from X9.42, specified in [CMSALG]. For RSAES-OAEP, see [RSAOAEP].
SHA-256を使用したRSassa-PSSについては、[rsapss]を参照してください。1024ビットDHについては、[cmsalg]を参照してください。1024ビット以下のDHについては、[SP800-56A]を参照してください。とにかく、[cmsalg]で指定されたx9.42からのKDFを使用します。rsaes-oaepについては、[rsaoaep]を参照してください。
The following are the requirements for an S/MIME agent generated RSA, RSASSA-PSS, and DSA signatures:
以下は、RSA、RSASSA-PSS、およびDSA署名を生成したS/MIMEエージェントの要件です。
key size <= 1023 : SHOULD NOT (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for S/MIME receiving agents during signature verification of RSA, RSASSA-PSS, and DSA signatures:
以下は、RSA、RSASSA-PSS、およびDSA署名の署名検証中のS/MIME受信エージェントの要件です。
key size <= 1023 : MAY (see Security Considerations)
1024 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent when establishing keys for content encryption using the RSA, RSA-OAEP, and DH algorithms:
RSA、RSA-OAEP、およびDHアルゴリズムを使用してコンテンツ暗号化のキーを確立する際のS/MIMEエージェントの要件は次のとおりです。
key size <= 1023 : SHOULD NOT (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent when establishing keys for content decryption using the RSA, RSAES-OAEP, and DH algorithms:
RSA、RSAES-OAEP、およびDHアルゴリズムを使用してコンテンツ復号化のキーを確立する際のS/MIMEエージェントの要件は次のとおりです。
key size <= 1023 : MAY (see Security Considerations)
1024 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following information updates the media type registration for application/pkcs7-mime and application/pkcs7-signature to refer to this document as opposed to RFC 2311.
以下の情報は、RFC 2311とは対照的に、このドキュメントを参照するために、アプリケーション/PKCS7-MIMEおよびアプリケーション/PKCS7シグネートのメディアタイプの登録を更新します。
Note that other documents can define additional MIME media types for S/MIME.
他のドキュメントでは、S/MIME用の追加のMIMEメディアタイプを定義できることに注意してください。
Type name: application
タイプ名：アプリケーション
Subtype Name: pkcs7-mime
サブタイプ名：pkcs7-mime
Required Parameters: NONE Optional Parameters: smime-type/signed-data smime-type/enveloped-data smime-type/compressed-data smime-type/certs-only name
必要なパラメーター：なしオプションのパラメーター：SMIME-TYPE/SIGNED-DATA SMIME-TYPE/ENVERVERTED-DATA SMIME-TYPE/Conpresd-Data Smime-Type/CERTSのみの名前
Encoding Considerations: See Section 3 of this document
考慮事項のエンコード：このドキュメントのセクション3を参照してください
Security Considerations: See Section 6 of this document
セキュリティ上の考慮事項：このドキュメントのセクション6を参照してください
Interoperability Considerations: See Sections 1-6 of this document
相互運用性の考慮事項：このドキュメントのセクション1〜6を参照してください
Published Specification: RFC 2311, RFC 2633, and this document
公開された仕様：RFC 2311、RFC 2633、およびこのドキュメント
Applications that use this media type: Security applications
このメディアタイプを使用するアプリケーション：セキュリティアプリケーション
Additional information: NONE
追加情報：なし
Person & email to contact for further information: S/MIME working group chairs smime-chairs@tools.ietf.org
詳細については、連絡先への個人とメール：S/MIMEワーキンググループチェアスマイムチェア@tools.ietf.org
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: NONE
使用に関する制限：なし
Author: Sean Turner
著者：ショーン・ターナー
Change Controller: S/MIME working group delegated from the IESG
Change Controller：IESGから委任されたS/MIMEワーキンググループ
Type name: application
タイプ名：アプリケーション
Subtype Name: pkcs7-signature
サブタイプ名：PKCS7-Signature
Required Parameters: NONE
必要なパラメーター：なし
Optional Parameters: NONE
オプションのパラメーター：なし
Encoding Considerations: See Section 3 of this document
考慮事項のエンコード：このドキュメントのセクション3を参照してください
Security Considerations: See Section 6 of this document
セキュリティ上の考慮事項：このドキュメントのセクション6を参照してください
Interoperability Considerations: See Sections 1-6 of this document
相互運用性の考慮事項：このドキュメントのセクション1〜6を参照してください
Published Specification: RFC 2311, RFC 2633, and this document
公開された仕様：RFC 2311、RFC 2633、およびこのドキュメント
Applications that use this media type: Security applications Additional information: NONE
このメディアタイプを使用するアプリケーション：セキュリティアプリケーション追加情報：なし
Person & email to contact for further information: S/MIME working group chairs smime-chairs@tools.ietf.org
詳細については、連絡先への個人とメール：S/MIMEワーキンググループチェアスマイムチェア@tools.ietf.org
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: NONE
使用に関する制限：なし
Author: Sean Turner
著者：ショーン・ターナー
Change Controller: S/MIME working group delegated from the IESG
Change Controller：IESGから委任されたS/MIMEワーキンググループ
Cryptographic algorithms will be broken or weakened over time. Implementers and users need to check that the cryptographic algorithms listed in this document continue to provide the expected level of security. The IETF from time to time may issue documents dealing with the current state of the art. For example:
暗号化アルゴリズムは、時間の経過とともに破損または弱体化します。実装者とユーザーは、このドキュメントにリストされている暗号化アルゴリズムが引き続き予想されるセキュリティレベルを提供していることを確認する必要があります。IETFは随時、現在の最新技術を扱う文書を発行する場合があります。例えば：
- The Million Message Attack described in RFC 3218 [MMA].
- RFC 3218 [MMA]に記載されている百万のメッセージ攻撃。
- The Diffie-Hellman "small-subgroup" attacks described in RFC 2785 [DHSUB].
- RFC 2785 [DHSUB]に記載されているDiffie-Hellmanの「小型グループ」攻撃。
- The attacks against hash algorithms described in RFC 4270 [HASH-ATTACK].
- RFC 4270 [ハッシュアタック]で説明されているハッシュアルゴリズムに対する攻撃。
This specification uses Public-Key Cryptography technologies. It is assumed that the private key is protected to ensure that it is not accessed or altered by unauthorized parties.
この仕様では、パブリックキー暗号化技術を使用しています。秘密鍵は、許可されていない当事者によってアクセスまたは変更されないように保護されていると想定されています。
It is impossible for most people or software to estimate the value of a message's content. Further, it is impossible for most people or software to estimate the actual cost of recovering an encrypted message content that is encrypted with a key of a particular size. Further, it is quite difficult to determine the cost of a failed decryption if a recipient cannot process a message's content. Thus, choosing between different key sizes (or choosing whether to just use plaintext) is also impossible for most people or software. However, decisions based on these criteria are made all the time, and therefore this specification gives a framework for using those estimates in choosing algorithms.
ほとんどの人やソフトウェアがメッセージのコンテンツの価値を推定することは不可能です。さらに、ほとんどの人やソフトウェアが、特定のサイズのキーで暗号化された暗号化されたメッセージコンテンツを回復する実際のコストを推定することは不可能です。さらに、受信者がメッセージのコンテンツを処理できない場合、復号化に失敗したコストを判断することは非常に困難です。したがって、さまざまなキーサイズを選択する（または、Plantextを使用するだけであるかどうかを選択する）ことも、ほとんどの人やソフトウェアでは不可能です。ただし、これらの基準に基づいた決定は常に行われるため、この仕様はアルゴリズムを選択する際にそれらの推定値を使用するためのフレームワークを提供します。
The choice of 2048 bits as the RSA asymmetric key size in this specification is based on the desire to provide at least 100 bits of security. The key sizes that must be supported to conform to this specification seem appropriate for the Internet based on [STRENGTH]. Of course, there are environments, such as financial and medical systems, that may select different key sizes. For this reason, an implementation MAY support key sizes beyond those recommended in this specification.
この仕様のRSA非対称キーサイズとしての2048ビットの選択は、少なくとも100ビットのセキュリティを提供したいという欲求に基づいています。この仕様に準拠するためにサポートする必要があるキーサイズは、[強さ]に基づいてインターネットに適しているようです。もちろん、金融や医療システムなどの環境には、異なるキーサイズを選択する可能性があります。このため、実装は、この仕様で推奨されるものを超えるキーサイズをサポートする場合があります。
Receiving agents that validate signatures and sending agents that encrypt messages need to be cautious of cryptographic processing usage when validating signatures and encrypting messages using keys larger than those mandated in this specification. An attacker could send certificates with keys that would result in excessive cryptographic processing, for example, keys larger than those mandated in this specification, which could swamp the processing element. Agents that use such keys without first validating the certificate to a trust anchor are advised to have some sort of cryptographic resource management system to prevent such attacks.
署名を検証する受信エージェントとメッセージを暗号化するエージェントを送信するエージェントは、この仕様で義務付けられているものよりも大きいキーを使用して署名を検証し、キーを使用してメッセージを暗号化する際に暗号化処理の使用に注意する必要があります。攻撃者は、たとえば、この仕様で義務付けられているものよりも大きいキーを使用するキーを使用して証明書を送信できます。最初に証明書を信託アンカーに検証することなくそのようなキーを使用するエージェントは、そのような攻撃を防ぐために何らかの暗号化リソース管理システムを持つことをお勧めします。
Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of AES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography.
S/MIMEで弱い暗号化を使用すると、プレーンテキストの送信に関する実際のセキュリティはほとんどありません。ただし、AEの仕様や、通信するパーティーに強力な暗号化機能を発表する能力など、S/MIMEの他の機能により、送信者は強力な暗号化を使用するメッセージを作成できます。唯一の代替手段が暗号化されていない場合を除き、弱い暗号化を使用することは決して推奨されません。
RSA and DSA keys of less than 1024 bits are now considered by many experts to be cryptographically insecure (due to advances in computing power), and should no longer be used to protect messages. Such keys were previously considered secure, so processing previously received signed and encrypted mail will often result in the use of weak keys. Implementations that wish to support previous versions of S/MIME or process old messages need to consider the security risks that result from smaller key sizes (e.g., spoofed messages) versus the costs of denial of service. If an implementation supports verification of digital signatures generated with RSA and DSA keys of less than 1024 bits, it MUST warn the user. Implementers should consider providing different warnings for newly received messages and previously stored messages. Server implementations (e.g., secure mail list servers) where user warnings are not appropriate SHOULD reject messages with weak signatures.
1024ビット未満のRSAおよびDSAキーは、多くの専門家によって（コンピューティングパワーの進歩のため）暗号化されていないと考えられており、メッセージの保護に使用されなくなったと考えられています。このようなキーは以前に安全であると見なされていたため、以前に受信した署名済みおよび暗号化されたメールを処理すると、しばしば弱いキーが使用されます。S/MIMEまたはProcessの古いメッセージの以前のバージョンをサポートしたい実装は、より小さなキーサイズ（たとえば、スプーフィングされたメッセージ）とサービスの拒否のコストから生じるセキュリティリスクを考慮する必要があります。実装が1024ビット未満のRSAおよびDSAキーで生成されたデジタル署名の検証をサポートする場合、ユーザーに警告する必要があります。実装者は、新しく受信したメッセージと以前に保存されたメッセージに対してさまざまな警告を提供することを検討する必要があります。ユーザーの警告が適切でない場合は、サーバーの実装（たとえば、セキュアなメールリストサーバー）は、弱い署名でメッセージを拒否する必要があります。
Implementers SHOULD be aware that multiple active key pairs can be associated with a single individual. For example, one key pair can be used to support confidentiality, while a different key pair can be used for digital signatures.
実装者は、複数のアクティブなキーペアが1人の個人に関連付けられる可能性があることに注意する必要があります。たとえば、1つのキーペアを使用して機密性をサポートできますが、デジタル署名には別のキーペアを使用できます。
If a sending agent is sending the same message using different strengths of cryptography, an attacker watching the communications channel might be able to determine the contents of the strongly encrypted message by decrypting the weakly encrypted version. In other words, a sender SHOULD NOT send a copy of a message using weaker cryptography than they would use for the original of the message.
送信エージェントが暗号化の異なる強みを使用して同じメッセージを送信している場合、コミュニケーションチャネルを監視する攻撃者は、弱く暗号化されたバージョンを復号化することにより、強く暗号化されたメッセージの内容を決定できる可能性があります。言い換えれば、送信者は、メッセージのオリジナルに使用するよりも、弱い暗号化を使用してメッセージのコピーを送信してはなりません。
Modification of the ciphertext can go undetected if authentication is not also used, which is the case when sending EnvelopedData without wrapping it in SignedData or enclosing SignedData within it.
認証も使用されていない場合、暗号文の変更は検出されない可能性があります。これは、SignedDataで包むことなくEnvelopedDataを送信したり、その中にSignedDataを囲んだりする場合です。
If an implementation is concerned about compliance with National Institute of Standards and Technology (NIST) key size recommendations, then see [SP800-57].
実装が国立標準および技術研究所（NIST）の主要なサイズの推奨事項への準拠に懸念されている場合は、[SP800-57]を参照してください。
If messaging environments make use of the fact that a message is signed to change the behavior of message processing (examples would be running rules or UI display hints), without first verifying that the message is actually signed and knowing the state of the signature, this can lead to incorrect handling of the message. Visual indicators on messages may need to have the signature validation code checked periodically if the indicator is supposed to give information on the current status of a message.
メッセージング環境が、メッセージ処理の動作を変更するためにメッセージに署名されているという事実を利用している場合（例はルールを実行したり、UIがヒントを表示します）。メッセージの処理が誤っている可能性があります。メッセージの視覚インジケーターは、インジケーターがメッセージの現在のステータスに関する情報を提供することになっている場合、定期的に署名検証コードをチェックする必要がある場合があります。
[CMS] refers to [RFC5652].
[CMS]は[RFC5652]を指します。
[ESS] refers to [RFC2634] and [RFC5035].
[ess]は[RFC2634]および[RFC5035]を指します。
[MIME] refers to [RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], and [RFC4289].
[MIME]は、[RFC 2045]、[RFC 2046]、[RFC 2047]、[RFC 2049]、[RFC4288]、および[RFC4289]を指します。
[SMIMEv2] refers to [RFC2311], [RFC2312], [RFC2313], [RFC2314], and [RFC2315].
[SMIMEV2]は、[RFC2311]、[RFC2312]、[RFC2313]、[RFC2314]、および[RFC2315]を指します。
[SMIMEv3] refers to [RFC2630], [RFC2631], [RFC2632], [RFC2633], [RFC2634], and [RFC5035].
[SMIMEV3]は、[RFC2630]、[RFC2631]、[RFC2632]、[RFC2633]、[RFC2634]、および[RFC5035]を指します。
[SMIMv3.1] refers to [RFC2634], [RFC3850], [RFC3851], [RFC3852], and [RFC5035].
[SMIMV3.1]は、[RFC2634]、[RFC3850]、[RFC3851]、[RFC3852]、および[RFC5035]を指します。
[CERT32] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010.
[CERT32] Ramsdell、B。およびS. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2証明書処理」、RFC 5750、2010年1月。
[CHARSETS] Character sets assigned by IANA. See http://www.iana.org/assignments/character-sets.
[charsets] ianaによって割り当てられた文字セット。http://www.iana.org/assignments/character-setsを参照してください。
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMSAES] Schaad、J。、「暗号化メッセージ構文（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月。
[CMS-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[CMS-Sha2] Turner、S。、「暗号化メッセージの構文を使用したSha2アルゴリズムを使用」、RFC 5754、2010年1月。
[CONTDISP] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[Contdisp] Troost、R.、Dorner、S。、およびK. Moore、ed。、「インターネットメッセージでのプレゼンテーション情報の通信：コンテンツ拡散ヘッダーフィールド」、RFC 2183、1997年8月。
[FIPS186-2] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS Publication 186-2, January 2000. [With Change Notice 1].
[FIPS186-2]国立標準技術研究所（NIST）、「デジタル署名標準（DSS）」、FIPS Publication 186-2、2000年1月。
[FIPS186-3] National Institute of Standards and Technology (NIST), FIPS Publication 186-3: Digital Signature Standard, June 2009.
[FIPS186-3]国立標準技術研究所（NIST）、FIPS Publication 186-3：Digital Signature Standard、2009年6月。
[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月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K。、「MIME（多目的インターネットメールエクステンション）パート3：ASCII以外のテキスト用のメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC2049] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[RFC2634] Hoffman, P. Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[RFC2634] Hoffman、P。Ed。、「S/MIMEの強化されたセキュリティサービス」、RFC 2634、1999年6月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
[RFC4289] Freed、N。およびJ. Klensin、「多目的インターネットメールエクステンション（MIME）パート4：登録手順」、BCP 13、RFC 4289、2005年12月。
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
[RFC5035] Schaad、J。、「Enhanced Security Services（ESS）アップデート：CertID Algorithm Agilityの追加」、RFC 5035、2007年8月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 5652、2009年9月。
[RSAOAEP] Housley, R. "Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[RSAOAEP] Housley、R。
[RSAPSS] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, June 2005.
[RSAPSS] Schaad、J。、「暗号化メッセージ構文（CMS）でのRSASSA-PSS署名アルゴリズムの使用」、RFC 4056、2005年6月。
[SP800-56A] National Institute of Standards and Technology (NIST), Special Publication 800-56A: Recommendation Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised), March 2007.
[SP800-56A]国立標準技術研究所（NIST）、特別出版800-56A：2007年3月、個別の対数暗号化（改訂）を使用した推奨ペアワイズキー確立スキーム。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X.680] ITU-T推奨X.680（2002）|ISO/IEC 8824-1：2002。情報技術 - 要約構文表記1（ASN.1）：基本表記の仕様。
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X.690] ITU-T推奨X.690（2002）|ISO/IEC 8825-1：2002。情報技術-ASN.1エンコーディングルール：基本エンコードルール（BER）、標準エンコーディングルール（CER）、および区別エンコードルール（DER）の仕様。
[DHSUB] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.
[DHSUB] Zuccherato、R。、「S/MIMEのDiffie-Hellman Key Asmaterメソッドに対する「小型」攻撃を回避する方法」、RFC 2785、2000年3月。
[HASH-ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[ハッシュアタック] Hoffman、P。and B. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、2005年11月。
[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月。
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[RFC2311] Dusse、S.、Hoffman、P.、Ramsdell、B.、Lundblade、L。、およびL. Repka、「S/Mimeバージョン2メッセージ仕様」、RFC 2311、1998年3月。
[RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, "S/MIME Version 2 Certificate Handling", RFC 2312, March 1998.
[RFC2312] Dusse、S.、Hoffman、P.、Ramsdell、B。、およびJ. Weinstein、「S/Mimeバージョン2証明書ハンドリング」、RFC 2312、1998年3月。
[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
[RFC2313] Kaliski、B。、「PKCS＃1：RSA暗号化バージョン1.5」、RFC 2313、1998年3月。
[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998.
[RFC2314] Kaliski、B。、 "PKCS＃10：認定要求構文バージョン1.5"、RFC 2314、1998年3月。
[RFC2315] Kaliski, B., "PKCS #7: Certification Message Syntax Version 1.5", RFC 2315, March 1998.
[RFC2315] Kaliski、B。、 "PKCS＃7：認定メッセージ構文バージョン1.5"、RFC 2315、1998年3月。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630] Housley、R。、「暗号化メッセージ構文」、RFC 2630、1999年6月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631] Rescorla、E。、「Diffie-Hellman Key Asmatement Method」、RFC 2631、1999年6月。
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999.
[RFC2632] Ramsdell、B.、ed。、「S/Mimeバージョン3証明書処理」、RFC 2632、1999年6月。
[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633] Ramsdell、B.、ed。、「S/Mimeバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[RFC3850] Ramsdell、B.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[SP800-57] National Institute of Standards and Technology (NIST), Special Publication 800-57: Recommendation for Key Management, August 2005.
[SP800-57]国立標準技術研究所（NIST）、特別出版800-57：主要な管理の推奨、2005年8月。
[STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[強さ] Orman、H。、およびP. Hoffman、「対称キーの交換に使用されるパブリックキーの強度の決定」、BCP 86、RFC 3766、2004年4月。
Note: The ASN.1 module contained herein is unchanged from RFC 3851 [SMIMEv3.1] with the exception of a change to the prefersBinaryInside ASN.1 comment. This module uses the 1988 version of ASN.1.
注：ここに含まれるASN.1モジュールは、RFC 3851 [SMIMEV3.1]から変更されていません。このモジュールは、1988年のASN.1のバージョンを使用しています。
SecureMimeMessageV3dot1
securemimemessagev3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
始める
IMPORTS
輸入
-- Cryptographic Message Syntax [CMS]
SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
-- id-aa is the arc with all new authenticated and unauthenticated
-- attributes produced by the S/MIME Working Group
id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
-- S/MIME Capabilities provides a method of broadcasting the
-- symmetric capabilities understood. Algorithms SHOULD be ordered
-- by preference and grouped by type
smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL }
SMIMECapabilities ::= SEQUENCE OF SMIMECapability
-- Encryption Key Preference provides a method of broadcasting the
-- preferred encryption certificate.
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}
-- receipentKeyId is spelt incorrectly, but kept for historical
-- reasons.
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
-- The preferBinaryInside OID indicates an ability to receive
-- messages with binary encoding inside the CMS wrapper.
-- The preferBinaryInside attribute's value field is ABSENT.
id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
-- The following list OIDs to be used with S/MIME V3
- 次のリストs/mime v3で使用するoids
-- Signature Algorithms Not Found in [CMSALG], [CMS-SHA2], [RSAPSS],
-- and [RSAOAEP]
--
-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 2}
--
-- Other Signed Attributes
--
-- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5}
-- See [CMS] for a description of how to encode the attribute
-- value.
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
-- (RC2 Key Length (number of bits))
END
終わり
Appendix B. Moving S/MIME v2 Message Specification to Historic Status
付録B. s/mimev2メッセージ仕様を歴史的ステータスに移動する
The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document) are backwards compatible with the S/MIME v2 Message Specification [SMIMEv2], with the exception of the algorithms (dropped RC2/40 requirement and added DSA and RSASSA-PSS requirements). Therefore, it is recommended that RFC 2311 [SMIMEv2] be moved to Historic status.
S/MIME V3 [SMIMEV3]、V3.1 [SMIMEV3.1]、およびV3.2（このドキュメント）は、アルゴリズムを除き、S/MIME V2メッセージ仕様[SMIMEV2]と逆方向に互換性があります（RC2をドロップしました。/40要件とDSAおよびRSASSA-PSSの要件を追加）。したがって、RFC 2311 [SMIMEV2]を歴史的なステータスに移動することをお勧めします。
Many thanks go out to the other authors of the S/MIME version 2 Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Lundblade, and Lisa Repka. Without v2, there wouldn't be a v3, v3.1, or v3.2.
S/Mimeバージョン2メッセージ仕様RFCの他の著者に感謝します：Steve Dusse、Paul Hoffman、Laurence Lundblade、およびLisa Repka。V2がなければ、v3、v3.1、またはv3.2はありません。
A number of the members of the S/MIME Working Group have also worked very hard and contributed to this document. Any list of people is doomed to omission, and for that I apologize. In alphabetical order, the following people stand out in my mind because they made direct contributions to this document:
S/MIMEワーキンググループの多くのメンバーも非常に一生懸命働いており、この文書に貢献しています。人々のリストは省略する運命にあります、そしてそのために私は謝罪します。アルファベット順に、この文書に直接貢献したため、次の人々は私の頭の中で際立っています。
Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, John Pawling, and Jim Schaad.
トニー・カペル、ピアーズ・チーバー、デイブ・クロッカー、ビル・フラニガン、ピーター・ガットマン、アルフレッド・ホーネス、ポール・ホフマン、ラス・ハウズリー、ウィリアム・オタウェイ、ジョン・ポーリング、ジム・シャード。
Authors' Addresses
著者のアドレス
Blake Ramsdell Brute Squad Labs, Inc.
Blake Ramsdell Brute Squad Labs、Inc。
EMail: blaker@gmail.com
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA、Inc。3057 Nutley Street、Suite 106 Fairfax、VA 22031 USA
EMail: turners@ieca.com