RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3851
タイトル : RFC 3851 - S/MIME バージョン 3.1 メッセージ仕様
翻訳編集 : 自動生成

[要約] RFC 3851は、電子メールにデジタル署名と暗号化を適用するための標準プロトコルであるS/MIME (Secure/Multipurpose Internet Mail Extensions) Version 3.1のメッセージ仕様を定義し、以前のRFC 2633を更新しました。MIMEエンティティを暗号メッセージ構文（CMS）で保護するための符号化手順、およびアルゴリズムの最小要件を規定しています。インターネットメールにおいて、商用レベルの高度なセキュリティと異なる製品間での確実な相互運用性を実現することを目的としています。

Network Working Group                                B. Ramsdell, Editor
Request for Comments: 3851                                Sendmail, Inc.
Obsoletes: 2633                                                July 2004
Category: Standards Track

Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification

S/MIME バージョン 3.1 メッセージ仕様

Status of this Memo

本文書の状態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

著作権（c）The Internet Society（2004）。

Abstract

概要

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633.

この文書ではSecure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1を定義します。S/MIMEは、安全なMIMEデータを一貫した方法で送受信します。デジタル署名は認証、メッセージ完全性、および送信元を証明する否認防止を提供します。暗号化はデータの機密性を提供します。圧縮を使ってデータサイズを削減できます。本書はRFC 2633を廃止します。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Specification Overview . . . . . . . . . . . . . . . . .  3
       1.2.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  3
       1.3.  Definitions. . . . . . . . . . . . . . . . . . . . . . .  4
       1.4.  Compatibility with Prior Practice of S/MIME. . . . . . .  5
       1.5.  Changes Since S/MIME v3. . . . . . . . . . . . . . . . .  5
   2.  CMS Options. . . . . . . . . . . . . . . . . . . . . . . . . .  5
       2.1.  DigestAlgorithmIdentifier. . . . . . . . . . . . . . . .  5
       2.2.  SignatureAlgorithmIdentifier . . . . . . . . . . . . . .  6
       2.3.  KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . .  6
       2.4.  General Syntax . . . . . . . . . . . . . . . . . . . . .  6
       2.5.  Attributes and the SignerInfo Type . . . . . . . . . . .  7
       2.6.  SignerIdentifier SignerInfo Type . . . . . . . . . . . . 11
       2.7.  ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 12
   3.  Creating S/MIME Messages . . . . . . . . . . . . . . . . . . . 14

       3.1.  Preparing the MIME Entity for Signing, Enveloping
             or Compressing . . . . . . . . . . . . . . . . . . . . . 14
       3.2.  The application/pkcs7-mime Type. . . . . . . . . . . . . 19
       3.3.  Creating an Enveloped-only Message . . . . . . . . . . . 21
       3.4.  Creating a Signed-only Message . . . . . . . . . . . . . 22
       3.5.  Creating an Compressed-only Message. . . . . . . . . . . 26
       3.6.  Multiple Operations. . . . . . . . . . . . . . . . . . . 27
       3.7.  Creating a Certificate Management Messagetoc . . . . . . 27
       3.8.  Registration Requests. . . . . . . . . . . . . . . . . . 28
       3.9.  Identifying an S/MIME Message. . . . . . . . . . . . . . 28
   4.  Certificate Processing . . . . . . . . . . . . . . . . . . . . 29
       4.1.  Key Pair Generation. . . . . . . . . . . . . . . . . . . 29
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 29
   A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
   B.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
       B.1.  Normative References . . . . . . . . . . . . . . . . . . 32
       B.2.  Informative References . . . . . . . . . . . . . . . . . 34
   C.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
   D.  Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 35
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36

1. Introduction

1. はじめに

S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures), and data confidentiality (using encryption).

S/MIME（Secure/Multipurpose Internet Mail Extensions）は、安全なMIMEデータを一貫した方法で送受信します。広く使われているインターネットMIME標準に基づき、S/MIMEは電子メッセージングアプリケーションに暗号学的なセキュリティサービスを提供します。サービスには、デジタル署名による認証、メッセージ完全性および送信元の否認防止と、暗号化によるデータ機密性が含まれます。

S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems.

S/MIMEは従来のメールユーザーエージェント（MUA）で使用でき、送信メールに暗号学的なセキュリティサービスを追加し、受信メールのセキュリティサービスを解釈できます。ただし、S/MIMEの用途はメールに限られません。HTTPなど、MIMEデータを運ぶあらゆるトランスポート機構で使用できます。このように、S/MIMEはMIMEのオブジェクトベースの機能を活用し、複数のトランスポートが混在するシステムでも安全なメッセージを交換できます。

Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet.

さらに、S/MIMEは、ソフトウェアで生成されたドキュメントの署名やインターネット経由で送信されたFAXメッセージの暗号化など、人間の介入を必要としない暗号化セキュリティサービスを使用する自動化されたメッセージ転送エージェントで使用できます。

1.1. Specification Overview

1.1. 仕様の概要

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. The MIME standard [MIME-SPEC] provides a general structure for the content type of Internet messages and allows extensions for new content type applications.

この文書では、MIMEデータに暗号学的な署名機能と暗号化機能を追加するプロトコルを説明します。MIME標準[MIME-SPEC]はインターネットメッセージのコンテンツタイプに共通の構造を提供し、新しいコンテンツタイプのアプリケーションへの拡張を可能にします。

This specification defines how to create a MIME body part that has been cryptographically enhanced according to CMS [CMS], which is derived from PKCS #7 [PKCS-7]. This specification also defines the application/pkcs7-mime MIME type that can be used to transport those body parts.

この仕様では、PKCS #7 [PKCS-7]から派生したCMS [CMS]に従って、暗号学的に保護されたMIMEボディパートを作成する方法を定義します。また、そのボディパートの転送に使用できるapplication/pkcs7-mime MIMEタイプも定義します。

This document also discusses how to use the multipart/signed MIME type defined in [MIME-SECURE] to transport S/MIME signed messages. multipart/signed is used in conjunction with the application/pkcs7- signature MIME type, which is used to transport a detached S/MIME signature.

この文書では、[MIME-SECURE]で定義するmultipart/signed MIMEタイプを使って、S/MIME署名付きメッセージを転送する方法も説明します。multipart/signedはapplication/pkcs7-signature MIMEタイプと組み合わせて使用し、分離署名されたS/MIME署名を転送します。

In order to create S/MIME messages, an S/MIME agent MUST follow the specifications in this document, as well as the specifications listed in the Cryptographic Message Syntax document [CMS] [CMSALG].

S/MIMEメッセージを作成するには、S/MIMEエージェントは、このドキュメントの仕様と、暗号化メッセージSyntaxドキュメント[CMS] [CMSAlg]にリストされている仕様に従わなければなりません (MUST)。

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種類のエージェントの要件と推奨事項は、必要に応じて個別にリストされます。

1.2. Terminology

1.2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUSTSHOULD].

本書で使うキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、[MUSTSHOULD]に記載された意味で解釈します。

1.3. Definitions

1.3. 定義

For the purposes of this specification, the following definitions apply.

この仕様の目的のために、次の定義が適用されます。

ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208 [X.208-88].

ASN.1: CCITT X.208 [X.208-88]で定義されるAbstract Syntax Notation One（抽象構文記法第1版）。

BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209 [X.209-88].

BER：CCITT X.209 [X.209-88]で定義されているASN.1の基本エンコードルール。

Certificate: A type that binds an entity's name to a public key with a digital signature.

証明書：エンティティの名前をデジタル署名を使用して公開キーにバインドするタイプ。

DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT X.509 [X.509-88].

DER: CCITT X.509 [X.509-88]で定義されるASN.1のDistinguished Encoding Rules。

7-bit data: Text data with lines less than 998 characters long, where none of the characters have the 8th bit set, and there are no NULL characters. <CR> and <LF> occur only as part of a <CR><LF> end of line delimiter.

7-bit data: 各行が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-bit data: 各行が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エージェント：受信エージェント、送信エージェント、またはその両方であるユーザーソフトウェア。

1.4. Compatibility with Prior Practice of S/MIME

1.4. S/MIMEの従来の運用との互換性

S/MIME version 3.1 agents SHOULD attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive and S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive. RFC 2311 also has historical information about the development of S/MIME.

S/MIMEバージョン3.1のエージェントは、旧バージョンのS/MIMEエージェントとの相互運用性を可能な限り高めるよう努めるべきです (SHOULD)。S/MIMEバージョン2はRFC 2311からRFC 2315（両方を含む）で、バージョン3はRFC 2630からRFC 2634（両方を含む）で説明されています。RFC 2311には、S/MIME開発の経緯も記載されています。

1.5. Changes Since S/MIME v3

1.5. S/MIME v3からの変更点

The RSA public key algorithm was changed to a MUST implement key wrapping algorithm, and the Diffie-Hellman algorithm changed to a SHOULD implement.

RSA公開鍵アルゴリズムは、実装しなければならない鍵ラッピングアルゴリズムに変更されました (MUST)。Diffie-Hellmanアルゴリズムは、実装すべきアルゴリズムに変更されました (SHOULD)。

The AES symmetric encryption algorithm has been included as a SHOULD implement.

AES対称暗号アルゴリズムが、実装すべきアルゴリズムとして追加されました (SHOULD)。

The RSA public key algorithm was changed to a MUST implement signature algorithm.

RSA公開鍵アルゴリズムは、実装しなければならない署名アルゴリズムに変更されました (MUST)。

Ambiguous language about the use of "empty" SignedData messages to transmit certificates was clarified to reflect that transmission of certificate revocation lists is also allowed.

証明書を転送するために「空」のSignedDataメッセージを使用する場合の曖昧な記述を明確にし、証明書失効リストも転送できることを反映しました。

The use of binary encoding for some MIME entities is now explicitly discussed.

一部のMIMEエンティティのバイナリエンコーディングの使用については、現在明示的に説明しています。

Header protection through the use of the message/rfc822 MIME type has been added.

message/rfc822 MIMEタイプの使用によるヘッダー保護が追加されました。

Use of the CompressedData CMS type is allowed, along with required MIME type and file extension additions.

CompressedData CMSタイプの使用を認め、必要なMIMEタイプとファイル拡張子の追加も説明しました。

2. CMS Options

2. CMSオプション

CMS allows for a wide variety of options in content and algorithm support. This section puts forth a number of support requirements and recommendations in order to achieve a base level of interoperability among all S/MIME implementations. [CMSALG] provides additional details regarding the use of the cryptographic algorithms.

CMSは、コンテンツとアルゴリズムのサポートにさまざまなオプションを可能にします。このセクションでは、すべてのS/MIME実装の間で相互運用性の基本レベルを達成するために、多くのサポート要件と推奨事項を示します。[CMSALG]は、暗号化アルゴリズムの使用に関する追加の詳細を提供します。

2.1. DigestAlgorithmIdentifier

Sending and receiving agents MUST support SHA-1 [CMSALG]. Receiving agents SHOULD support MD5 [CMSALG] for the purpose of providing backward compatibility with MD5-digested S/MIME v2 SignedData objects.

送信エージェントと受信エージェントはSHA-1 [CMSALG]をサポートしなければなりません (MUST)。受信エージェントは、MD5でダイジェストされたS/MIME v2 SignedDataオブジェクトとの後方互換性のため、MD5 [CMSALG]もサポートすべきです (SHOULD)。

2.2. SignatureAlgorithmIdentifier

Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. The algorithm parameters MUST be absent (not encoded as NULL). Receiving agents MUST support rsaEncryption, defined in [CMSALG].

受信エージェントは、[CMSALG] で定義されたid-dsa-with-sha1をサポートしなければなりません (MUST)。アルゴリズムパラメーターは省略しなければなりません (MUST)（NULLとしてエンコードしないこと）。受信エージェントは、[CMSALG] で定義されたrsaEncryptionをサポートしなければなりません (MUST)。

Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.

送信エージェントは、id-dsa-with-sha1またはrsaEncryptionのいずれかをサポートしなければなりません (MUST)。

If using rsaEncryption, sending and receiving agents MUST support the digest algorithms in section 2.1 as specified.

rsaEncryptionを使用している場合、指定されているようにセクション2.1のダイジェストアルゴリズムを送信および受信エージェントがサポートしなければなりません (MUST)。

Note that S/MIME v3 clients might only implement signing or signature verification using id-dsa-with-sha1, and might also use id-dsa as an AlgorithmIdentifier in this field. Receiving clients SHOULD recognize id-dsa as equivalent to id-dsa-with-sha1, and sending clients MUST use id-dsa-with-sha1 if using that algorithm. Also note that S/MIME v2 clients are only required to verify digital signatures using the rsaEncryption algorithm with SHA-1 or MD5, and might not implement id-dsa-with-sha1 or id-dsa at all.

S/MIME v3クライアントは、id-dsa-with-sha1を使った署名または署名検証だけを実装している場合があり、このフィールドのAlgorithmIdentifierにid-dsaを使う場合もあります。受信クライアントはid-dsaをid-dsa-with-sha1と同等として認識すべきです (SHOULD)。送信クライアントがこのアルゴリズムを使う場合は、id-dsa-with-sha1を使わなければなりません (MUST)。また、S/MIME v2クライアントには、SHA-1またはMD5を使ったrsaEncryptionアルゴリズムによるデジタル署名の検証だけが求められており、id-dsa-with-sha1やid-dsaをまったく実装していない場合があります。

2.3. KeyEncryptionAlgorithmIdentifier

Sending and receiving agents MUST support rsaEncryption, defined in [CMSALG].

送信エージェントと受信エージェントは、[CMSALG]で定義するrsaEncryptionをサポートしなければなりません (MUST)。

Sending and receiving agents SHOULD support Diffie-Hellman defined in [CMSALG], using the ephemeral-static mode.

送信エージェントと受信エージェントは、ephemeral-staticモードを使うDiffie-Hellman [CMSALG]もサポートすべきです (SHOULD)。

Note that S/MIME v3 clients might only implement key encryption and decryption using the Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only capable of decrypting content-encryption keys using the rsaEncryption algorithm.

S/MIME v3クライアントは、Diffie-Hellmanアルゴリズムによる鍵の暗号化と復号だけを実装している場合があります。また、S/MIME v2クライアントがコンテンツ暗号鍵を復号できるのは、rsaEncryptionアルゴリズムを使う場合に限られます。

2.4. General Syntax

2.4. 一般構文

There are several CMS content types. Of these, only the Data, SignedData, EnvelopedData, and CompressedData content types are currently used for S/MIME.

複数のCMSコンテンツタイプがあります。このうち、現在S/MIMEで使用するのはData、SignedData、EnvelopedData、CompressedDataの各コンテンツタイプだけです。

2.4.1. Data Content Type

Sending agents MUST use the id-data content type identifier to identify the "inner" MIME message content. For example, when applying a digital signature to MIME data, the CMS SignedData encapContentInfo eContentType MUST include the id-data object identifier and the MIME content MUST be stored in the SignedData encapContentInfo eContent OCTET STRING (unless the sending agent is using multipart/signed, in which case the eContent is absent, per section 3.4.3 of this document). As another example, when applying encryption to MIME data, the CMS EnvelopedData encryptedContentInfo contentType MUST include the id-data object identifier and the encrypted MIME content MUST be stored in the EnvelopedData encryptedContentInfo encryptedContent OCTET STRING.

送信エージェントは、内側のMIMEメッセージコンテンツを識別するために、id-dataコンテンツタイプ識別子を使用しなければなりません (MUST)。たとえば、MIMEデータにデジタル署名を適用する場合、CMS SignedDataのencapContentInfoのeContentTypeにid-dataオブジェクト識別子を含めなければなりません (MUST)。multipart/signedを使う場合（本書のセクション3.4.3に従ってeContentは存在しません）を除き、MIMEコンテンツをSignedDataのencapContentInfoのeContent OCTET STRINGに格納しなければなりません (MUST)。同様に、MIMEデータを暗号化する場合、CMS EnvelopedDataのencryptedContentInfoのcontentTypeにid-dataオブジェクト識別子を含めなければなりません (MUST)。暗号化したMIMEコンテンツはEnvelopedDataのencryptedContentInfoのencryptedContent OCTET STRINGに格納しなければなりません (MUST)。

2.4.2. SignedData Content Type

2.4.2. SignedDataコンテンツタイプ

Sending agents MUST use the SignedData content type to apply a digital signature to a message or, in a degenerate case where there is no signature information, to convey certificates. Applying a signature to a message provides authentication, message integrity, and non-repudiation of origin.

送信エージェントは、メッセージにデジタル署名を適用する場合、または署名情報のない特殊なケースで証明書を伝える場合に、SignedDataコンテンツタイプを使用しなければなりません (MUST)。メッセージに署名することで、認証、メッセージ完全性、および送信元の否認防止が得られます。

2.4.3. EnvelopedData Content Type

2.4.3. EnvelopedDataコンテンツタイプ

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.

このコンテンツタイプは、データの機密性をメッセージに適用するために使用されます。送信者は、意図した各メッセージ受信者がこのサービスを使用するために公開キーにアクセスできる必要があります。

2.4.4. CompressedData Content Type

This content type is used to apply data compression to a message. This content type does not provide authentication, message integrity, non-repudiation, or data confidentiality, and is only used to reduce message size.

このコンテンツタイプは、メッセージを圧縮するために使用します。認証、メッセージ完全性、送信元の否認防止、データ機密性は提供せず、メッセージサイズの削減だけを目的とします。

See section 3.6 for further guidance on the use of this type in conjunction with other CMS types.

他のCMSタイプと組み合わせて、このタイプの使用に関するさらなるガイダンスについては、セクション3.6を参照してください。

2.5. Attributes and the SignerInfo Type

2.5. 属性とSignerInfoタイプ

The SignerInfo type allows the inclusion of unsigned and signed attributes to be included along with a signature.

SignerInfo型では、署名に署名付き属性と署名なし属性を含めることができます。

Receiving agents MUST be able to handle zero or one instance of each of the signed attributes listed here. Sending agents SHOULD generate one instance of each of the following signed attributes in each S/MIME message:

受信エージェントは、ここにリストされている各署名属性のゼロまたは1つのインスタンスを処理できなければなりません (MUST)。送信エージェントは、各S/MIMEメッセージに次の各署名属性の1つのインスタンスを生成すべきです (SHOULD)。

- signingTime (section 2.5.1 in this document) - sMIMECapabilities (section 2.5.2 in this document) - sMIMEEncryptionKeyPreference (section 2.5.3 in this document) - id-messageDigest (section 11.2 in [CMS]) - id-contentType (section 11.1 in [CMS]) Further, receiving agents SHOULD be able to handle zero or one instance in the signingCertificate signed attribute, as defined in section 5 of [ESS].

- signingTime（本文書のセクション2.5.1） - sMIMECapabilities（本文書のセクション2.5.2） - sMIMEEncryptionKeyPreference（本文書のセクション2.5.3） - id-messageDigest（[CMS] のセクション11.2） - id-contentType（[CMS] のセクション11.1）さらに、受信エージェントは、[ESS] のセクション5で定義されるsigningCertificate署名属性について、0個または1個のインスタンスを扱えるべきです (SHOULD)。

Sending agents SHOULD generate one instance of the signingCertificate signed attribute in each SignerInfo structure.

送信エージェントは、各SignerInfo構造にsigningCertificate署名属性の1つのインスタンスを生成すべきです (SHOULD)。

Additional attributes and values for these attributes might be defined in the future. Receiving agents SHOULD handle attributes or values that it does not recognize in a graceful manner.

将来、これらの属性や値が追加で定義される場合があります。受信エージェントは、認識できない属性や値を適切に処理すべきです (SHOULD)。

Interactive sending agents that include signed attributes that are not listed here SHOULD display those attributes to the user, so that the user is aware of all of the data being signed.

ここにリストされていない署名属性を含むインタラクティブな送信エージェントは、ユーザーが署名されているすべてのデータを認識できるように、ユーザーにそれらの属性を表示すべきです (SHOULD)。

2.5.1. Signing-Time Attribute

2.5.1. 署名時刻属性

The signing-time attribute is used to convey the time that a message was signed. The time of signing will most likely be created by a message originator and therefore is only as trustworthy as the originator.

signing-time属性は、メッセージに署名した時刻を伝えます。署名時刻は通常メッセージ送信者が生成するため、その信頼性は送信者の信頼性と同程度です。

Sending agents MUST encode signing time through the year 2049 as UTCTime; signing times in 2050 or later MUST be encoded as GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST interpret the year field (YY) as follows:

送信エージェントは、2049年までの署名時刻をUTCTimeとして符号化しなければなりません (MUST)。2050年以降の署名時刻はGeneralizedTimeとして符号化しなければなりません (MUST)。UTCTimeのCHOICEを使用する場合、S/MIMEエージェントは年のフィールド（YY）を次のように解釈しなければなりません (MUST):

if YY is greater than or equal to 50, the year is interpreted as 19YY; if YY is less than 50, the year is interpreted as 20YY.

YYが50以上なら年を19YYと解釈し、YYが50未満なら年を20YYと解釈します。

2.5.2. SMIMECapabilities Attribute

The SMIMECapabilities attribute includes signature algorithms (such as "sha1WithRSAEncryption"), symmetric algorithms (such as "DES-EDE3-CBC"), and key encipherment algorithms (such as "rsaEncryption"). There are also several identifiers which indicate support for other optional features such as binary encoding and compression. The SMIMECapabilities were designed to be flexible and extensible so that, in the future, a means of identifying other capabilities and preferences such as certificates can be added in a way that will not cause current clients to break.

SMIMECapabilities属性には、署名アルゴリズム（例: "sha1WithRSAEncryption"）、対称アルゴリズム（例: "DES-EDE3-CBC"）、鍵暗号化アルゴリズム（例: "rsaEncryption"）が含まれます。また、バイナリエンコーディングや圧縮など、他の任意機能をサポートしていることを示す識別子も複数あります。SMIMECapabilitiesは柔軟で拡張可能な設計であり、将来、現在のクライアントに影響を与えずに、証明書などの機能や選好を識別する手段を追加できます。

If present, the SMIMECapabilities attribute MUST be a SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the SMIMECapabilities attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A SMIMECapabilities attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.

存在する場合、SMIMECapabilities属性はSignedAttributeでなければなりません (MUST)。UnsignedAttributeであってはなりません (MUST NOT)。CMSではSignedAttributesをAttributeのSET OFとして定義します。signerInfo内のSignedAttributesに、SMIMECapabilities属性を複数含めてはなりません (MUST NOT)。CMSでは、AttributeのASN.1構文にattrValues（AttributeValueのSET OF）を含めます。SMIMECapabilities属性にはAttributeValueを1つだけ含めなければなりません (MUST)。attrValues（AttributeValueのSET OF）にAttributeValueが0個または複数含まれていてはなりません (MUST NOT)。

The semantics of the SMIMECapabilities attribute specify a partial list as to what the client announcing the SMIMECapabilities can support. A client does not have to list every capability it supports, and need not list all its capabilities so that the capabilities list doesn't get too long. In an SMIMECapabilities attribute, the object identifiers (OIDs) are listed in order of their preference, but SHOULD be separated logically along the lines of their categories (signature algorithms, symmetric algorithms, key encipherment algorithms, etc.)

SMIMECapabilities属性は、これを通知するクライアントがサポートできる機能の一部を示します。クライアントはサポートする機能をすべて列挙する必要はなく、一覧が長くなりすぎないよう一部を省略できます。SMIMECapabilities属性では、OIDを選好順に並べますが、カテゴリ（署名アルゴリズム、対称アルゴリズム、鍵暗号化アルゴリズムなど）ごとに論理的に分けるべきです (SHOULD)。

The structure of the SMIMECapabilities attribute is to facilitate simple table lookups and binary comparisons in order to determine matches. For instance, the DER-encoding for the SMIMECapability for DES EDE3 CBC MUST be identically encoded regardless of the implementation. Because of the requirement for identical encoding, individuals documenting algorithms to be used in the SMIMECapabilities attribute SHOULD explicitly document the correct byte sequence for the common cases.

SMIMECapabilities属性は、対応する機能を特定するための単純な表引きとバイナリ比較を可能にする構造です。たとえば、DES EDE3 CBCのSMIMECapabilityは、実装にかかわらず同一のDER符号化でなければなりません (MUST)。同一の符号化が必要なため、SMIMECapabilities属性で使用するアルゴリズムを文書化する者は、一般的なケースの正しいバイト列を明記すべきです (SHOULD)。

For any capability, the associated parameters for the OID MUST specify all of the parameters necessary to differentiate between two instances of the same algorithm. For instance, the number of rounds and the block size for RC5 needs to be specified in addition to the key length.

どの機能についても、OIDに関連付けられたパラメーターは、同じアルゴリズムの2つのインスタンスを区別するのに必要なすべてのパラメーターを指定しなければなりません (MUST)。例えば、RC5では、鍵長に加えてラウンド数とブロックサイズを指定する必要があります。

The OIDs that correspond to algorithms SHOULD use the same OID as the actual algorithm, except in the case where the algorithm usage is ambiguous from the OID. For instance, in an earlier specification, rsaEncryption was ambiguous because it could refer to either a signature algorithm or a key encipherment algorithm. In the event that an OID is ambiguous, it needs to be arbitrated by the maintainer of the registered SMIMECapabilities list as to which type of algorithm will use the OID, and a new OID MUST be allocated under the smimeCapabilities OID to satisfy the other use of the OID.

アルゴリズムに対応するOIDには、OIDだけでは用途が曖昧になる場合を除き、実際のアルゴリズムと同じOIDを使うべきです (SHOULD)。たとえば、以前の仕様ではrsaEncryptionが署名アルゴリズムと鍵暗号化アルゴリズムのどちらも指し得るため、曖昧でした。OIDが曖昧な場合、登録済みSMIMECapabilitiesリストの管理者が、どの種類のアルゴリズムにそのOIDを使うか裁定する必要があります。もう一方の用途に対応するため、smimeCapabilities OIDの下に新しいOIDを割り当てなければなりません (MUST)。

The registered SMIMECapabilities list specifies the parameters for OIDs that need them, most notably key lengths in the case of variable-length symmetric ciphers. In the event that there are no differentiating parameters for a particular OID, the parameters MUST be omitted, and MUST NOT be encoded as NULL.

登録済みのSMIMECapabilitiesリストでは、パラメーターを必要とするOIDのパラメーターを指定します。特に、可変長の対称暗号では鍵長を指定します。特定のOIDで区別に使うパラメーターがない場合、パラメーターを省略しなければならず (MUST)、NULLとして符号化してはなりません (MUST NOT)。

Additional values for the SMIMECapabilities attribute might be defined in the future. Receiving agents MUST handle a SMIMECapabilities object that has values that it does not recognize in a graceful manner.

SMIMECapabilities属性の値は将来追加で定義される場合があります。受信エージェントは、認識できない値を含むSMIMECapabilitiesオブジェクトを適切に処理しなければなりません (MUST)。

Section 2.7.1 explains a strategy for caching capabilities.

セクション2.7.1では、機能情報をキャッシュする方法を説明します。

2.5.2.1. SMIMECapability For the RC2 Algorithm

2.5.2.1. SMIMECapability for the RC2 Algorithm

For the RC2 algorithm preference SMIMECapability, the capabilityID MUST be set to the value rc2-cbc as defined in [CMSALG]. The parameters field MUST contain SMIMECapabilitiesParametersForRC2CBC (see appendix A).

RC2アルゴリズムのSMIMECapabilityでは、capabilityIDを[CMSALG]で定義する値rc2-cbcに設定しなければなりません (MUST)。parametersフィールドにはSMIMECapabilitiesParametersForRC2CBC（付録Aを参照）を含めなければなりません (MUST)。

Please note that the SMIMECapabilitiesParametersForRC2CBC is a single INTEGER which contains the effective key length (NOT the corresponding RC2 parameter version value). So, for example, for RC2 with a 128-bit effective key length, the parameter would be encoded as the INTEGER value 128, NOT the corresponding parameter version of 58.

SMIMECapabilitiesParametersForRC2CBCは、有効鍵長を格納する単一のINTEGERです（対応するRC2 parameter version値ではありません）。たとえば、有効鍵長が128ビットのRC2では、パラメーターはINTEGER値128として符号化します。対応するparameter version値58ではありません。

2.5.3. Encryption Key Preference Attribute

2.5.3. 暗号化鍵選好属性

The encryption key preference attribute allows the signer to unambiguously describe which of the signer's certificates has the signer's preferred encryption key. This attribute is designed to enhance behavior for interoperating with those clients that use separate keys for encryption and signing. This attribute is used to convey to anyone viewing the attribute which of the listed certificates is appropriate for encrypting a session key for future encrypted messages.

暗号化鍵選好属性を使うと、署名者は、自分の証明書のうちどれに優先する暗号化鍵が含まれるかを明確に示せます。この属性は、暗号化と署名で別々の鍵を使うクライアントとの相互運用性を高めるためのものです。この属性を閲覧する人に対し、将来の暗号化メッセージのセッション鍵を暗号化するのに適した証明書が一覧のどれかを伝えます。

If present, the SMIMEEncryptionKeyPreference attribute MUST be a SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A SMIMEEncryptionKeyPreference attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.

存在する場合、SMIMEEncryptionKeyPreference属性はSignedAttributeでなければなりません (MUST)。UnsignedAttributeであってはなりません (MUST NOT)。CMSではSignedAttributesをAttributeのSET OFとして定義します。signerInfo内のSignedAttributesに、SMIMEEncryptionKeyPreference属性を複数含めてはなりません (MUST NOT)。CMSでは、AttributeのASN.1構文にattrValues（AttributeValueのSET OF）を含めます。SMIMEEncryptionKeyPreference属性にはAttributeValueを1つだけ含めなければなりません (MUST)。attrValues（AttributeValueのSET OF）にAttributeValueが0個または複数含まれていてはなりません (MUST NOT)。

The sending agent SHOULD include the referenced certificate in the set of certificates included in the signed message if this attribute is used. The certificate MAY be omitted if it has been previously made available to the receiving agent. Sending agents SHOULD use this attribute if the commonly used or preferred encryption certificate is not the same as the certificate used to sign the message.

この属性を使用する場合、送信エージェントは、署名されたメッセージに含まれる証明書の集合に、参照される証明書を含めるべきです (SHOULD)。その証明書が以前に受信エージェントに提供されている場合は、省略してもよいです (MAY)。一般的に使用される、または優先される暗号化証明書がメッセージの署名に使用した証明書と同じでない場合、送信エージェントはこの属性を使用すべきです (SHOULD)。

Receiving agents SHOULD store the preference data if the signature on the message is valid and the signing time is greater than the currently stored value. (As with the SMIMECapabilities, the clock skew SHOULD be checked and the data not used if the skew is too great.) Receiving agents SHOULD respect the sender's encryption key preference attribute if possible. This, however, represents only a preference and the receiving agent can use any certificate in replying to the sender that is valid.

メッセージの署名が有効であり、署名時刻が現在保存されている値よりも新しい場合、受信エージェントは優先情報を保存すべきです (SHOULD)。（SMIMECapabilitiesと同様に、クロックのずれを確認すべきであり (SHOULD)、ずれが大きすぎる場合はデータを使用しません。）受信エージェントは、可能であれば、送信者の暗号化鍵の優先属性を尊重すべきです (SHOULD)。ただし、これは優先を表すにすぎず、受信エージェントは送信者への返信に任意の有効な証明書を使用できます。

Section 2.7.1 explains a strategy for caching preference data.

セクション2.7.1では、選好情報をキャッシュする方法を説明します。

2.5.3.1. Selection of Recipient Key Management Certificate

2.5.3.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 EnvelopedDataメッセージを送る際に使用する鍵管理証明書を決定するには、次の手順に従うべきです (SHOULD):

- If an SMIMEEncryptionKeyPreference attribute is found in a SignedData object received from the desired recipient, this identifies the X.509 certificate that SHOULD be used as the X.509 key management certificate for the recipient.

- 目的の受信者から受信したSignedDataオブジェクトにSMIMEEncryptionKeyPreference属性が含まれている場合、その値が受信者の鍵管理証明書として使用すべきX.509証明書を示します (SHOULD)。

- If an SMIMEEncryptionKeyPreference attribute is not found in a SignedData object received from the desired recipient, the set of X.509 certificates SHOULD be searched for a X.509 certificate with the same subject name as the signing of a X.509 certificate which can be used for key management.

- 目的の受信者から受信したSignedDataオブジェクトにSMIMEEncryptionKeyPreference属性がない場合、鍵管理に使用できるX.509証明書のうち、署名用X.509証明書とsubject nameが同じ証明書を探すべきです (SHOULD)。

- Or use some other method of determining the user's key management key. If a X.509 key management certificate is not found, then encryption cannot be done with the signer of the message. If multiple X.509 key management certificates are found, the S/MIME agent can make an arbitrary choice between them.

- または、ユーザーの鍵管理鍵を特定する別の方法を使います。X.509鍵管理証明書が見つからない場合、メッセージ署名者向けの暗号化はできません。複数のX.509鍵管理証明書が見つかった場合、S/MIMEエージェントはその中から任意に選択できます。

2.6. SignerIdentifier SignerInfo Type

2.6. SignerIdentifier SignerInfoタイプ

S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as well as subjectKeyIdentifier. Messages that use the subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.

S/MIME v3.1の実装は、issuerAndSerialNumberとsubjectKeyIdentifierの両方をサポートしなければなりません (MUST)。subjectKeyIdentifierを使うメッセージはS/MIME v2クライアントでは読み取れません。

It is important to understand that some certificates use a value for subjectKeyIdentifier that is not suitable for uniquely identifying a certificate. Implementations MUST be prepared for multiple certificates for potentially different entities to have the same value for subjectKeyIdentifier, and MUST be prepared to try each matching certificate during signature verification before indicating an error condition.

subjectKeyIdentifierの値が、証明書を一意に識別するのに適さない証明書もあることを理解する必要があります。実装は、異なるエンティティに属する可能性のある複数の証明書が同じsubjectKeyIdentifier値を持つ場合に備えなければなりません (MUST)。また、エラーを示す前に、署名検証で一致する各証明書を試さなければなりません (MUST)。

2.7. ContentEncryptionAlgorithmIdentifier

Sending and receiving agents MUST support encryption and decryption with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Receiving agents SHOULD support encryption and decryption using the RC2 [CMSALG] or a compatible algorithm at a key size of 40 bits, hereinafter called "RC2/40". Sending and receiving agents SHOULD support encryption and decryption with AES [CMSAES] at a key size of 128, 192, and 256 bits.

送信エージェントと受信エージェントは、DES EDE3 CBC（以下「tripleDES」と呼びます）[CMSALG]による暗号化と復号をサポートしなければなりません (MUST)。受信エージェントは、40ビット鍵のRC2 [CMSALG]または互換アルゴリズム（以下「RC2/40」と呼びます）による暗号化と復号をサポートすべきです (SHOULD)。送信エージェントと受信エージェントは、128、192、256ビット鍵のAES [CMSAES]による暗号化と復号もサポートすべきです (SHOULD)。

2.7.1. Deciding Which Encryption Method To Use

2.7.1. 使用する暗号方式の決定

When a sending agent creates an encrypted message, it has to decide which type of encryption to use. The decision process involves using information garnered from the capabilities lists included in messages received from the recipient, as well as out-of-band information such as private agreements, user preferences, legal restrictions, and so on.

送信エージェントが暗号化メッセージを作成するときは、使用する暗号方式を決める必要があります。この判断では、受信者からのメッセージに含まれる機能一覧のほか、個別の合意、ユーザーの選好、法的制約など、別経路で得た情報も使います。

Section 2.5.2 defines a method by which a sending agent can optionally announce, among other things, its decrypting capabilities in its order of preference. The following method for processing and remembering the encryption capabilities attribute in incoming signed messages SHOULD be used.

セクション2.5.2では、送信エージェントが復号機能などを選好順に通知できる方法を定義します。受信した署名付きメッセージの暗号機能属性は、次の方法で処理し、記録すべきです (SHOULD)。

- If the receiving agent has not yet created a list of capabilities for the sender's public key, then, after verifying the signature on the incoming message and checking the timestamp, the receiving agent SHOULD create a new list containing at least the signing time and the symmetric capabilities.

- 受信エージェントが送信者の公開鍵に対する機能のリストをまだ作成していない場合、受信エージェントは、受信メッセージの署名を検証してタイムスタンプを確認した後、少なくとも署名時刻と対称暗号の機能を含む新しいリストを作成すべきです (SHOULD)。

- If such a list already exists, the receiving agent SHOULD verify that the signing time in the incoming message is greater than the signing time stored in the list and that the signature is valid. If so, the receiving agent SHOULD update both the signing time and capabilities in the list. Values of the signing time that lie far in the future (that is, a greater discrepancy than any reasonable clock skew), or a capabilities list in messages whose signature could not be verified, MUST NOT be accepted.

- すでに一覧がある場合、受信エージェントは、受信メッセージの署名時刻が一覧に保存された時刻より新しく、署名が有効であることを確認すべきです (SHOULD)。条件を満たす場合は、一覧の署名時刻と機能の両方を更新すべきです (SHOULD)。遠い未来の署名時刻（妥当なクロックずれを超える差がある場合）や、署名を検証できなかったメッセージの機能一覧は受け入れてはなりません (MUST NOT)。

The list of capabilities SHOULD be stored for future use in creating messages.

機能一覧は、今後メッセージを作成する際に使えるよう保存すべきです (SHOULD)。

Before sending a message, the sending agent MUST decide whether it is willing to use weak encryption for the particular data in the message. If the sending agent decides that weak encryption is unacceptable for this data, then the sending agent MUST NOT use a weak algorithm such as RC2/40. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use.

メッセージを送信する前に、送信エージェントは、メッセージ内の特定のデータに弱い暗号化を使用する意思があるかどうかを決定しなければなりません (MUST)。送信エージェントがこのデータに対して弱い暗号化が受け入れられないと判断した場合、送信エージェントはRC2/40などの弱いアルゴリズムを使用してはなりません (MUST NOT)。弱い暗号化を使用または使用しないという決定は、このセクションで使用する暗号化アルゴリズムについて他の決定を上書きします。

Sections 2.7.2.1 through 2.7.2.4 describe the decisions a sending agent SHOULD use in deciding which type of encryption will be applied to a message. These rules are ordered, so the sending agent SHOULD make its decision in the order given.

2.7.2.1節から2.7.2.4節では、メッセージにどの種類の暗号化を適用するかを決める際に送信エージェントが用いるべき (SHOULD) 判断を説明します。これらの規則には順序があるため、送信エージェントは示された順序で判断すべきです (SHOULD)。

2.7.1.1. Rule 1: Known Capabilities

2.7.1.1. ルール1：既知の機能

If the sending agent has received a set of capabilities from the recipient for the message the agent is about to encrypt, then the sending agent SHOULD use that information by selecting the first capability in the list (that is, the capability most preferred by the intended recipient) that the sending agent knows how to encrypt. The sending agent SHOULD use one of the capabilities in the list if the agent reasonably expects the recipient to be able to decrypt the message.

送信エージェントが、暗号化しようとしているメッセージの受信者から機能一覧を受け取っている場合、その一覧のうち、送信エージェントが使用でき、受信者が最も優先する最初の機能を選ぶべきです (SHOULD)。受信者がメッセージを復号できると合理的に期待できる場合、一覧にある機能のいずれかを使うべきです (SHOULD)。

2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME

2.7.1.2. ルール2：不明な機能、S/MIMEの不明なバージョン

If the following two conditions are met: - the sending agent has no knowledge of the encryption capabilities of the recipient, - and the sending agent has no knowledge of the version of S/MIME of the recipient, then the sending agent SHOULD use tripleDES because it is a stronger algorithm and is required by S/MIME v3. If the sending agent chooses not to use tripleDES in this step, it SHOULD use RC2/40.

次の2つの条件を満たす場合、送信エージェントは、より強力でS/MIME v3が必須としているtripleDESを使うべきです (SHOULD): 受信者の暗号機能を知らないこと、かつ受信者が使うS/MIMEのバージョンを知らないことです。この段階でtripleDESを使わない場合は、RC2/40を使うべきです (SHOULD)。

2.7.2. Choosing Weak Encryption

2.7.2. 弱い暗号化の選択

Like all algorithms that use 40 bit keys, RC2/40 is considered by many to be weak encryption. A sending agent that is controlled by a human SHOULD allow a human sender to determine the risks of sending data using RC2/40 or a similarly weak encryption algorithm before sending the data, and possibly allow the human to use a stronger encryption method such as tripleDES.

40ビット鍵を使うRC2/40は、多くの暗号学者から弱い暗号と見なされています。RC2/40や同程度に弱い暗号を使ってデータを送るリスクを、送信前に人間の送信者が判断できるよう、人間が操作する送信エージェントはその機会を提供すべきです (SHOULD)。また、tripleDESなど、より強い暗号方式を選べるようにしてもかまいません。

2.7.3. Multiple Recipients

2.7.3. 複数の受信者

If a sending agent is composing an encrypted message to a group of recipients where the encryption capabilities of some of the recipients do not overlap, the sending agent is forced to send more than one message. Please note that if the sending agent chooses to 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.

暗号強度の異なる方式で同じメッセージを送信すると、通信経路を監視する攻撃者が弱い暗号化版を復号し、強い暗号化版の内容を知る可能性があります。つまり、送信者は元のメッセージに使う暗号より弱い暗号で、そのコピーを送信すべきではありません (SHOULD NOT)。

3. Creating S/MIME Messages

3. S/MIMEメッセージの作成

This section describes the S/MIME message formats and how they are created. S/MIME messages are a combination of MIME bodies and CMS content types. Several MIME types as well as several CMS content types are used. The data to be secured is always a canonical MIME entity. The MIME entity and other data, such as certificates and algorithm identifiers, are given to CMS processing facilities which produce a CMS object. Finally, the CMS object is wrapped in MIME. The Enhanced Security Services for S/MIME [ESS] document provides descriptions of how nested, secured S/MIME messages are formatted. ESS provides a description of how a triple-wrapped S/MIME message is formatted using multipart/signed and application/pkcs7-mime for the signatures.

このセクションでは、S/MIMEメッセージの形式と作成方法を説明します。S/MIMEメッセージはMIMEボディとCMSコンテンツタイプを組み合わせて構成します。複数のMIMEタイプとCMSコンテンツタイプを使用します。保護するデータは常に正規形のMIMEエンティティです。MIMEエンティティや証明書、アルゴリズム識別子などのデータをCMS処理機能に渡すと、CMSオブジェクトが生成されます。最後に、そのCMSオブジェクトをMIMEで包みます。Enhanced Security Services for S/MIME [ESS]では、入れ子になった保護済みS/MIMEメッセージの形式を説明しています。またESSでは、署名にmultipart/signedとapplication/pkcs7-mimeを使った三重ラップS/MIMEメッセージの形式も説明しています。

S/MIME provides one format for enveloped-only data, several formats for signed-only data, and several formats for signed and enveloped data. Several formats are required to accommodate several environments, in particular for signed messages. The criteria for choosing among these formats are also described.

S/MIMEには、暗号化のみのデータ用、署名のみのデータ用、署名と暗号化の両方を行うデータ用の各形式があります。特に署名付きメッセージでは、さまざまな環境に対応するため複数の形式が必要です。各形式から選択する基準も説明します。

The reader of this section is expected to understand MIME as described in [MIME-SPEC] and [MIME-SECURE].

このセクションの読者は、[MIME-SPEC]および[MIME-SECURE]で説明されるMIMEを理解していることを前提とします。

3.1. Preparing the MIME Entity for Signing, Enveloping or Compressing

3.1. 署名、包囲、または圧縮するためのMIMEエンティティの準備

S/MIME is used to secure MIME entities. A MIME entity can be a sub-part, sub-parts of a message, or the whole message with all its sub-parts. A MIME entity that is the whole message includes only the MIME headers and MIME body, and does not include the RFC-822 headers. Note that S/MIME can also be used to secure MIME entities used in applications other than Internet mail. If protection of the RFC-822 headers is required, the use of the message/rfc822 MIME type is explained later in this section.

S/MIMEはMIMEエンティティを保護します。MIMEエンティティは、メッセージの一部、複数の部分、またはすべての部分を含むメッセージ全体です。メッセージ全体を表すMIMEエンティティに含まれるのはMIMEヘッダーとMIMEボディだけであり、RFC-822ヘッダーは含みません。S/MIMEはインターネットメール以外のアプリケーションで使うMIMEエンティティも保護できます。RFC-822ヘッダーを保護する必要がある場合に用いるmessage/rfc822 MIMEタイプについては、このセクションの後半で説明します。

The MIME entity that is secured and described in this section can be thought of as the "inside" MIME entity. That is, it is the "innermost" object in what is possibly a larger MIME message. Processing "outside" MIME entities into CMS content types is described in Section 3.2, 3.4, and elsewhere.

このセクションで保護し説明するMIMEエンティティを「内側」のMIMEエンティティと考えることができます。これは、より大きなMIMEメッセージの中にある最も内側のオブジェクトです。「外側」のMIMEエンティティをCMSコンテンツタイプに処理する方法は、セクション3.2、3.4などで説明します。

The procedure for preparing a MIME entity is given in [MIME-SPEC]. The same procedure is used here with some additional restrictions when signing. Description of the procedures from [MIME-SPEC] are repeated here, but it is suggested that the reader refer to that document for the exact procedure. This section also describes additional requirements.

MIMEエンティティの準備手順は[MIME-SPEC]に記載されています。署名する場合は追加の制約がありますが、ここでも同じ手順を使います。[MIME-SPEC]の手順をここで繰り返しますが、正確な手順については同文書を参照してください。このセクションでは追加要件も説明します。

A single procedure is used for creating MIME entities that are to have any combination of signing, enveloping, and compressing applied. Some additional steps are recommended to defend against known corruptions that can occur during mail transport that are of particular importance for clear-signing using the multipart/signed format. It is recommended that these additional steps be performed on enveloped messages, or signed and enveloped messages, so that the message can be forwarded to any environment without modification.

署名、暗号化、圧縮を任意に組み合わせて適用するMIMEエンティティは、共通の手順で作成します。メール転送中に起こり得る既知の破損、特にmultipart/signed形式でクリア署名を行う場合に問題となる破損を防ぐため、追加手順も推奨します。メッセージを変更せずにあらゆる環境へ転送できるよう、暗号化のみのメッセージや、署名と暗号化を施したメッセージにもこの追加手順を適用することを推奨します。

These steps are descriptive rather than prescriptive. The implementer is free to use any procedure as long as the result is the same.

これらの手順は規範的な指示ではなく、説明です。結果が同じであれば、実装者は任意の手順を使えます。

Step 1. The MIME entity is prepared according to the local conventions.

ステップ1. MIMEエンティティをローカルの規約に従って準備します。

Step 2. The leaf parts of the MIME entity are converted to canonical form.

ステップ2. MIMEエンティティの葉の部分は、標準形式に変換されます。

Step 3. Appropriate transfer encoding is applied to the leaves of the MIME entity.

ステップ3.適切な転送エンコーディングは、MIMEエンティティの葉に適用されます。

When an S/MIME message is received, the security services on the message are processed, and the result is the MIME entity. That MIME entity is typically passed to a MIME-capable user agent where, it is further decoded and presented to the user or receiving application.

S/MIMEメッセージを受信すると、メッセージに適用されたセキュリティサービスを処理し、MIMEエンティティを取り出します。通常、このMIMEエンティティはMIME対応ユーザーエージェントに渡され、そこでさらにデコードされてユーザーまたは受信アプリケーションに表示されます。

In order to protect outer, non-content related message headers (for instance, the "Subject", "To", "From" and "CC" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these headers. It is up to the receiving client to decide how to present these "inner" headers along with the unprotected "outer" headers.

外側の、コンテンツに関係しないメッセージヘッダー（例: "Subject"、"To"、"From"、"CC"）を保護するため、送信クライアントは完全なMIMEメッセージをmessage/rfc822ラッパーで包み、これらのヘッダーにもS/MIMEセキュリティサービスを適用してもよいです (MAY)。保護された内側のヘッダーを、保護されていない外側のヘッダーとともにどう表示するかは、受信クライアントが決めます。

When an S/MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822, it can be assumed that the intent was to provide header protection. This entity SHOULD be presented as the top-level message, taking into account header merging issues as previously discussed.

S/MIMEメッセージが受信されると、トップレベルの保護されたMIMEエンティティにmessage/rfc822のコンテンツタイプがある場合、ヘッダー保護を提供する意図があると想定できます。このエンティティは、以前に説明したように、ヘッダーのマージの問題を考慮して、トップレベルのメッセージとして提示すべきです (SHOULD)。

3.1.1. Canonicalization

3.1.1. 標準化

Each MIME entity MUST be converted to a canonical form that is uniquely and unambiguously representable in the environment where the signature is created and the environment where the signature will be verified. MIME entities MUST be canonicalized for enveloping and compressing as well as signing.

各MIMEエンティティは、署名が作成されている環境と署名が検証される環境で、独特かつ明確に表現できる標準形式に変換しなければなりません (MUST)。MIMEエンティティは、署名だけでなく包み込みと圧縮のために正規化されなければなりません (MUST)。

The exact details of canonicalization depend on the actual MIME type and subtype of an entity, and are not described here. Instead, the standard for the particular MIME type SHOULD be consulted. For example, canonicalization of type text/plain is different from canonicalization of audio/basic. Other than text types, most types have only one representation regardless of computing platform or environment which can be considered their canonical representation. In general, canonicalization will be performed by the non-security part of the sending agent rather than the S/MIME implementation.

正準化の詳細は、エンティティの実際のMIMEタイプとサブタイプによって異なるため、ここでは説明しません。代わりに、そのMIMEタイプの標準を参照すべきです (SHOULD)。たとえば、text/plainとaudio/basicでは正準化の方法が異なります。テキスト以外の大半のタイプは、コンピューティング環境にかかわらず表現が1つだけであり、それを正準表現とみなせます。一般に、正準化はS/MIME実装ではなく、送信エージェントのセキュリティ以外の部分が行います。

The most common and important canonicalization is for text, which is often represented differently in different environments. MIME entities of major type "text" MUST have both their line endings and character set canonicalized. The line ending MUST be the pair of characters <CR><LF>, and the charset SHOULD be a registered charset [CHARSETS]. The details of the canonicalization are specified in [MIME-SPEC]. The chosen charset SHOULD be named in the charset parameter so that the receiving agent can unambiguously determine the charset used.

最も一般的で重要な正準化は、環境によって表現が異なることの多いテキストに対するものです。メジャータイプが"text"のMIMEエンティティでは、行末と文字セットの両方を正準化しなければなりません (MUST)。行末は<CR><LF>の組でなければならず (MUST)、charsetには登録済みの文字セット[CHARSETS]を使うべきです (SHOULD)。正準化の詳細は[MIME-SPEC]に規定されています。受信エージェントが使用文字セットを一意に特定できるよう、選択したcharsetをcharsetパラメーターで指定すべきです (SHOULD)。

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などの文字セットでは、同じ文字に複数の表現があることに注意してください。そのようなテキストに署名する前に、文字セットで指定された正準表現を使用しなければなりません (MUST)。

3.1.2. Transfer Encoding

3.1.2. 転送エンコーディング

When generating any of the secured MIME entities below, except the signing using the multipart/signed format, no transfer encoding is required at all. S/MIME implementations MUST be able to deal with binary MIME objects. If no Content-Transfer-Encoding header is present, the transfer encoding is presumed to be 7BIT.

multipart/signed形式で署名する場合を除き、以下の保護対象MIMEエンティティを生成する際に転送エンコーディングは必要ありません。S/MIME実装はバイナリMIMEオブジェクトを扱えなければなりません (MUST)。Content-Transfer-Encodingヘッダーがない場合、転送エンコーディングは7BITとみなします。

S/MIME implementations SHOULD however use transfer encoding described in section 3.1.3 for all MIME entities they secure. The reason for securing only 7-bit MIME entities, even for enveloped data that are not exposed to the transport, is that it allows the MIME entity to be handled in any environment without changing it. For example, a trusted gateway might remove the envelope, but not the signature, of a message, and then forward the signed message on to the end recipient so that they can verify the signatures directly. If the transport internal to the site is not 8-bit clean, such as on a wide-area network with a single mail gateway, verifying the signature will not be possible unless the original MIME entity was only 7-bit data.

ただし、S/MIME実装は、保護するすべてのMIMEエンティティにセクション3.1.3で説明する転送エンコーディングを使うべきです (SHOULD)。転送経路に公開されない暗号化データも含め、7ビットMIMEエンティティだけを保護する主な理由は、MIMEエンティティを変更せずにどの環境でも扱えるためです。たとえば、信頼できるゲートウェイがメッセージの封筒だけを取り除いて署名を残し、受信者が署名を直接検証できるよう署名付きメッセージを転送する場合があります。サイト内の転送経路が8ビット透過でない場合、元のMIMEエンティティが7ビットデータだけでなければ署名を検証できません。

S/MIME implementations which "know" that all intended recipient(s) are capable of handling inner (all but the outermost) binary MIME objects SHOULD use binary encoding as opposed to a 7-bit-safe transfer encoding for the inner entities. The use of a 7-bit-safe encoding (such as base64) would unnecessarily expand the message size. Implementations MAY "know" that recipient implementations are capable of handling inner binary MIME entities either by interpreting the id-cap-preferBinaryInside sMIMECapabilities attribute, by prior agreement, or by other means.

意図するすべての受信者が内側（最外部以外）のバイナリMIMEオブジェクトを扱えると「分かっている」S/MIME実装は、内側のエンティティに7ビット安全な転送エンコーディングではなくバイナリエンコーディングを使うべきです (SHOULD)。Base64などの7ビット安全なエンコーディングを使うと、メッセージサイズが不必要に大きくなります。実装は、id-cap-preferBinaryInside SMIMECapabilities属性の解釈、事前の合意、または別の方法によって、受信側の実装が内側のバイナリMIMEエンティティを扱えると判断してもよいです (MAY)。

If one or more intended recipients are unable to handle inner binary MIME objects, or if this capability is unknown for any of the intended recipients, S/MIME implementations SHOULD use transfer encoding described in section 3.1.3 for all MIME entities they secure.

意図する受信者のうち1人以上が内側のバイナリMIMEオブジェクトを扱えない場合、または受信者のいずれかについてその能力が不明な場合、S/MIME実装は保護するすべてのMIMEエンティティにセクション3.1.3の転送エンコーディングを使うべきです (SHOULD)。

3.1.3. Transfer Encoding for Signing Using multipart/signed

3.1.3. multipart/signedを使う署名のための転送エンコーディング

If a multipart/signed entity is ever to be transmitted over the standard Internet SMTP infrastructure or other transport that is constrained to 7-bit text, it MUST have transfer encoding applied so that it is represented as 7-bit text. MIME entities that are 7-bit data already need no transfer encoding. Entities such as 8-bit text and binary data can be encoded with quoted-printable or base-64 transfer encoding.

multipart/signedエンティティを標準的なインターネットSMTP基盤など、7ビットテキストに制限されたトランスポートで送信する場合は、7ビットテキストとして表現できるよう転送エンコーディングを適用しなければなりません (MUST)。すでに7ビットデータであるMIMEエンティティには転送エンコーディングは不要です。8ビットテキストやバイナリデータはquoted-printableまたはbase64で符号化できます。

The primary reason for the 7-bit requirement is that the Internet mail transport infrastructure cannot guarantee transport of 8-bit or binary data. Even though many segments of the transport infrastructure now handle 8-bit and even binary data, it is sometimes not possible to know whether the transport path is 8-bit clean. If a mail message with 8-bit data were to encounter a message transfer agent that can not transmit 8-bit or binary data, the agent has three options, none of which are acceptable for a clear-signed message:

7ビット要件の主な理由は、インターネットメールの転送基盤が8ビットデータやバイナリデータの転送を保証できないことです。現在は基盤の多くの区間が8ビットやバイナリデータを扱えますが、転送経路全体が8ビット透過かどうかを判断できないことがあります。8ビットまたはバイナリデータを転送できないメッセージ転送エージェントに8ビットデータを含むメールが届くと、エージェントには次の3つの選択肢がありますが、クリア署名付きメッセージではどれも受け入れられません:

- The agent could change the transfer encoding; this would invalidate the signature. - The agent could transmit the data anyway, which would most likely result in the 8th bit being corrupted; this too would invalidate the signature. - The agent could return the message to the sender.

- エージェントが転送エンコーディングを変更すると、署名が無効になります。- エージェントがそのままデータを送信すると、第8ビットが破損する可能性が高く、やはり署名が無効になります。- エージェントがメッセージを送信者に返します。

[MIME-SECURE] prohibits an agent from changing the transfer encoding of the first part of a multipart/signed message. If a compliant agent that can not transmit 8-bit or binary data encounters a multipart/signed message with 8-bit or binary data in the first part, it would have to return the message to the sender as undeliverable.

[MIME-SECURE]は、multipart/signedメッセージの最初の部分の転送エンコーディングをエージェントが変更することを禁止しています。8ビットやバイナリデータを転送できない準拠エージェントが、最初の部分にそのようなデータを含むmultipart/signedメッセージを受信した場合、配信不能として送信者に返すことになります。

3.1.4. Sample Canonical MIME Entity

3.1.4. 標準的なmimeエンティティのサンプル

This example shows a multipart/mixed message with full transfer encoding. This message contains a text part and an attachment. The sample message text includes characters that are not US-ASCII and thus need to be transfer encoded. Though not shown here, the end of each line is <CR><LF>. The line ending of the MIME headers, the text, and transfer encoded parts, all MUST be <CR><LF>.

この例は、転送エンコーディングを適用したmultipart/mixedメッセージです。メッセージにはテキスト部分と添付ファイルが含まれます。本文にはUS-ASCII以外の文字が含まれるため、転送エンコーディングが必要です。例では示しませんが、各行の終端は<CR><LF>です。MIMEヘッダー、テキスト、転送符号化部分の行末はすべて<CR><LF>でなければなりません (MUST)。

Note that this example is not of an S/MIME message.

この例はS/MIMEメッセージではないことに注意してください。

       Content-Type: multipart/mixed; boundary=bar

       --bar
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: quoted-printable

=A1Hola Michael!

How do you like the new S/MIME specification?

It's generally a good idea to encode lines that begin with From=20because some mail transport agents will insert a greater-than (>) sign, thus invalidating the signature.

一部のメール転送エージェントは「>」記号を挿入して署名を無効にするため、From=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をエンコードするとよいことがあります。BITNETのようにその空白を変更するゲートウェイを通過しても、メッセージ署名が無効にならないようにするためです。

       --bar
       Content-Type: image/jpeg
       Content-Transfer-Encoding: base64

iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI=

--bar--

3.2. The application/pkcs7-mime Type

3.2. application/pkcs7-mimeタイプ

The application/pkcs7-mime type is used to carry CMS content types including EnvelopedData, SignedData, and CompressedData. The details of constructing these entities is described in subsequent sections. This section describes the general characteristics of the application/pkcs7-mime type.

application/pkcs7-mimeタイプは、EnvelopedData、SignedData、CompressedDataを含むCMSコンテンツタイプを運ぶために使用されます。これらのエンティティを構築する詳細は、後続の節で説明します。この節では、application/pkcs7-mimeタイプの一般的な特性について説明します。

The carried CMS object always contains a MIME entity that is prepared as described in section 3.1 if the eContentType is id-data. Other contents MAY be carried when the eContentType contains different values. See [ESS] for an example of this with signed receipts.

eContentTypeがid-dataの場合、運ばれるCMSオブジェクトにはセクション3.1に従って準備されたMIMEエンティティが常に含まれます。eContentTypeが別の値の場合は、他のコンテンツを含めてもよいです (MAY)。署名済み受領通知の例については[ESS]を参照してください。

Since CMS content types are binary data, in most cases base-64 transfer encoding is appropriate, in particular, when used with SMTP transport. The transfer encoding used depends on the transport through which the object is to be sent, and is not a characteristic of the MIME type.

CMSコンテンツタイプはバイナリデータであるため、多くの場合、特にSMTPで転送する場合はbase64転送エンコーディングが適切です。使用する転送エンコーディングはオブジェクトの送信経路によって決まり、MIMEタイプ自体の特性ではありません。

Note that this discussion refers to the transfer encoding of the CMS object or "outside" MIME entity. It is completely distinct from, and unrelated to, the transfer encoding of the MIME entity secured by the CMS object, the "inside" object, which is described in section 3.1.

この説明は、CMSオブジェクト、つまり外側のMIMEエンティティの転送エンコーディングを指しています。CMSオブジェクトで保護する内側のMIMEエンティティの転送エンコーディング（セクション3.1で説明）とは別のもので、関係もありません。

Because there are several types of application/pkcs7-mime objects, a sending agent SHOULD do as much as possible to help a receiving agent know about the contents of the object without forcing the receiving agent to decode the ASN.1 for the object. The MIME headers of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections.

application/pkcs7-mimeオブジェクトには複数の種類があるため、送信エージェントは、受信エージェントにASN.1をデコードさせずにオブジェクトの内容を把握できるよう、できる限りの情報を提供すべきです (SHOULD)。すべてのapplication/pkcs7-mimeオブジェクトのMIMEヘッダーには、後続の節で説明する任意の"smime-type"パラメーターを含めるべきです (SHOULD)。

3.2.1. The name and filename Parameters

3.2.1. 名前とファイル名のパラメーター

For the application/pkcs7-mime, sending agents SHOULD emit the optional "name" parameter to the Content-Type field for compatibility with older systems. Sending agents SHOULD also emit the optional Content-Disposition field [CONTDISP] with the "filename" parameter. If a sending agent emits the above parameters, the value of the parameters SHOULD be a file name with the appropriate extension: MIME Type File Extension

application/pkcs7-mimeの場合、送信エージェントは旧システムとの互換性のため、Content-Typeフィールドに任意の"name"パラメーターを出力すべきです (SHOULD)。また、"filename"パラメーターを持つContent-Dispositionフィールド[CONTDISP]も出力すべきです (SHOULD)。これらのパラメーターを出力する場合、その値は適切な拡張子を持つファイル名にすべきです (SHOULD): MIME Type / File Extension

application/pkcs7-mime (SignedData, EnvelopedData) .p7m

application/pkcs7-mime (degenerate SignedData .p7c certificate management message)

application/pkcs7-mime (CompressedData) .p7z

application/pkcs7-signature (SignedData) .p7s

In addition, the file name SHOULD be limited to eight characters followed by a three letter extension. The eight character filename base can be any distinct name; the use of the filename base "smime" SHOULD be used to indicate that the MIME entity is associated with S/MIME.

さらに、ファイル名は8文字以下の名前に3文字の拡張子を続けた形式にすべきです (SHOULD)。8文字のベース名には任意の固有名を使えます。MIMEエンティティがS/MIMEに関連することを示すには、ベース名に"smime"を使うべきです (SHOULD)。

Including a file name serves two purposes. It facilitates easier use of S/MIME objects as files on disk. It also can convey type information across gateways. When a MIME entity of type application/pkcs7-mime (for example) arrives at a gateway that has no special knowledge of S/MIME, it will default the entity's MIME type to application/octet-stream and treat it as a generic attachment, thus losing the type information. However, the suggested filename for an attachment is often carried across a gateway. This often allows the receiving systems to determine the appropriate application to hand the attachment off to, in this case, a stand-alone S/MIME processing application. Note that this mechanism is provided as a convenience for implementations in certain environments. A proper S/MIME implementation MUST use the MIME types and MUST NOT rely on the file extensions.

ファイル名には2つの役割があります。S/MIMEオブジェクトをディスク上のファイルとして扱いやすくすることと、ゲートウェイを越えてタイプ情報を伝えることです。たとえば、S/MIMEを認識しないゲートウェイにapplication/pkcs7-mime MIMEエンティティが届くと、ゲートウェイはそのMIMEタイプをapplication/octet-streamに置き換えて一般的な添付ファイルとして扱い、タイプ情報を失うことがあります。一方、添付ファイル名はゲートウェイを越えて伝わることが多く、受信システムが適切なアプリケーション（この場合は単独のS/MIME処理アプリケーション）を選ぶ助けになります。この仕組みは特定の環境での実装を便宜的に支援するものです。適切なS/MIME実装はMIMEタイプを使用しなければならず (MUST)、ファイル拡張子に依存してはなりません (MUST NOT)。

3.2.2. The smime-type parameter

3.2.2. smime-typeパラメーター

The application/pkcs7-mime content type defines the optional "smime-type" parameter. The intent of this parameter is to convey details about the security applied (signed or enveloped) along with information about the contained content. This specification defines the following smime-types.

application/pkcs7-mimeコンテンツタイプでは、任意のsmime-typeパラメーターを定義します。このパラメーターは、含まれるコンテンツの情報とともに、適用されたセキュリティ（署名または暗号化）の詳細を伝えるためのものです。本仕様では、次のsmime-typeを定義します。

   Name                   CMS type                Inner Content

enveloped-data EnvelopedData id-data

   signed-data            SignedData              id-data

   certs-only             SignedData              none

compressed-data CompressedData id-data

In order for consistency to be obtained with future specifications, the following guidelines SHOULD be followed when assigning a new smime-type parameter.

将来の仕様との一貫性を保つため、新しいsmime-typeパラメーターを割り当てる際は、次の指針に従うべきです (SHOULD)。

1. If both signing and encryption can be applied to the content, then two values for smime-type SHOULD be assigned "signed-*" and "encrypted-*". If one operation can be assigned then this can be omitted. Thus since "certs-only" can only be signed, "signed-" is omitted.

1. コンテンツに署名と暗号化の両方を適用できる場合、smime-typeには"signed-*"と"encrypted-*"の2つの値を割り当てるべきです (SHOULD)。一方の操作しか適用できない場合は、その接頭辞を省略できます。たとえば、"certs-only"は署名のみ可能なため、"signed-"を省略しています。

2. A common string for a content OID SHOULD be assigned. We use "data" for the id-data content OID when MIME is the inner content.

2. コンテンツOIDには共通の文字列を割り当てるべきです (SHOULD)。MIMEが内側のコンテンツである場合、id-dataコンテンツOIDには"data"を使用します。

3. If no common string is assigned. Then the common string of "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would be DES40).

3. 共通の文字列が割り当てられていない場合は、"OID.<oid>"という文字列を推奨します（たとえば、"OID.1.3.6.1.5.5.7.6.1"はDES40です）。

It is explicitly intended that this field be a suitable hint for mail client applications to indicate whether a message is "signed" or "encrypted" without having to tunnel into the CMS payload.

このフィールドは、CMSペイロードを解析しなくてもメッセージが「署名済み」か「暗号化済み」かをメールクライアントが判別できるようにするヒントとして明確に意図されています。

3.3. Creating an Enveloped-only Message

3.3. 暗号化のみのメッセージの作成

This section describes the format for enveloping a MIME entity without signing it. It is important to note that sending enveloped but not signed messages does not provide for data integrity. It is possible to replace ciphertext in such a way that the processed message will still be valid, but the meaning can be altered.

このセクションでは、署名せずにMIMEエンティティを暗号化する形式を説明します。署名なしで暗号化したメッセージを送っても、データ完全性は保証されません。暗号文を置き換えても処理後のメッセージが有効なままになることがあり、その場合、メッセージの意味が変わる可能性があります。

Step 1. The MIME entity to be enveloped is prepared according to section 3.1.

ステップ1.包み込むMIMEエンティティは、セクション3.1に従って準備されています。

Step 2. The MIME entity and other required data is processed into a CMS object of type EnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content-encryption key SHOULD be encrypted for the originator and included in the EnvelopedData (see [CMS] Section 6).

ステップ2. MIMEエンティティとその他の必要なデータを、EnvelopedData型のCMSオブジェクトに処理します。各受信者向けにコンテンツ暗号鍵のコピーを暗号化するほか、送信元向けにも鍵のコピーを暗号化してEnvelopedDataに含めるべきです (SHOULD)（[CMS]のセクション6を参照）。

Step 3. The EnvelopedData object is wrapped in a CMS ContentInfo object.

ステップ3. EnvelopedDataオブジェクトをCMS ContentInfoオブジェクトで包みます。

Step 4. The ContentInfo object is inserted into an application/pkcs7-mime MIME entity.

ステップ4. ContentInfoオブジェクトは、application/pkcs7-mime MIMEエンティティに挿入されます。

The smime-type parameter for enveloped-only messages is "enveloped-data". The file extension for this type of message is ".p7m".

暗号化のみのメッセージのsmime-typeパラメーターは"enveloped-data"です。このメッセージ形式のファイル拡張子は".p7m"です。

A sample message would be:

サンプルメッセージは次のとおりです。

       Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
            name=smime.p7m
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V

3.4. Creating a Signed-only Message

3.4. 署名のみのメッセージの作成

There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents MUST be able to handle both.

S/MIMEでは署名付きメッセージに2つの形式を定義しています。SignedDataを使うapplication/pkcs7-mime形式とmultipart/signed形式です。一般に送信時はmultipart/signed形式が望ましく、受信エージェントは両方を扱えなければなりません (MUST)。

3.4.1. Choosing a Format for Signed-only Messages

3.4.1. 署名のみのメッセージのフォーマットの選択

There are no hard-and-fast rules when a particular signed-only format is chosen because it depends on the capabilities of all the receivers and the relative importance of receivers with S/MIME facilities being able to verify the signature versus the importance of receivers without S/MIME software being able to view the message.

特定の署名のみ形式を選ぶための一律の規則はありません。選択は、すべての受信者の機能と、S/MIME機能を持つ受信者が署名を検証できることと、S/MIMEソフトウェアを持たない受信者がメッセージを読めることのどちらを重視するかによって決まります。

Messages signed using the multipart/signed format can always be viewed by the receiver whether they have S/MIME software or not. They can also be viewed whether they are using a MIME-native user agent or they have messages translated by a gateway. In this context, "be viewed" means the ability to process the message essentially as if it were not a signed message, including any other MIME structure the message might have.

multipart/signed形式で署名されたメッセージは、受信者がS/MIMEソフトウェアを持つかどうかにかかわらず表示できます。MIMEネイティブのユーザーエージェントでも、ゲートウェイがメッセージを変換した場合でも表示できます。ここで「表示できる」とは、メッセージに含まれる他のMIME構造も含め、署名されていないメッセージとほぼ同じように処理できることを意味します。

Messages signed using the SignedData format cannot be viewed by a recipient unless they have S/MIME facilities. However, the SignedData format protects the message content from being changed by benign intermediate agents. Such agents might do line wrapping or content-transfer encoding changes which would break the signature.

SignedData形式で署名されたメッセージは、受信者がS/MIME機能を持たないと表示できません。一方、SignedData形式は、中間エージェントによる意図しないメッセージ内容の変更から保護します。たとえば、中間エージェントが行う行の折り返しやContent-Transfer-Encodingの変更によって署名が壊れる場合があります。

3.4.2. Signing Using application/pkcs7-mime with SignedData

3.4.2. SignedDataを使ったapplication/pkcs7-mimeによる署名

This signing format uses the application/pkcs7-mime MIME type. The steps to create this format are:

この署名形式では、application/pkcs7-mime MIMEタイプを使用します。この形式を作成する手順は次のとおりです。

Step 1. The MIME entity is prepared according to section 3.1.

ステップ1. MIMEエンティティをセクション3.1に従って準備します。

Step 2. The MIME entity and other required data is processed into a CMS object of type SignedData.

ステップ2. MIMEエンティティとその他の必要なデータをSignedData型のCMSオブジェクトに処理します。

Step 3. The SignedData object is wrapped in a CMS ContentInfo object.

ステップ3. SignedDataオブジェクトをCMS ContentInfoオブジェクトで包みます。

Step 4. The ContentInfo object is inserted into an application/pkcs7-mime MIME entity.

ステップ4. ContentInfoオブジェクトをapplication/pkcs7-mime MIMEエンティティに挿入します。

The smime-type parameter for messages using application/pkcs7-mime with SignedData is "signed-data". The file extension for this type of message is ".p7m".

SignedDataを使うapplication/pkcs7-mimeメッセージのsmime-typeパラメーターは"signed-data"です。このメッセージ形式のファイル拡張子は".p7m"です。

A sample message would be:

サンプルメッセージは次のとおりです。

       Content-Type: application/pkcs7-mime; smime-type=signed-data;
            name=smime.p7m
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7m

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75

3.4.3. Signing Using the multipart/signed Format

3.4.3. multipart/signed形式を使った署名

This format is a clear-signing format. Recipients without any S/MIME or CMS processing facilities are able to view the message. It makes use of the multipart/signed MIME type described in [MIME-SECURE]. The multipart/signed MIME type has two parts. The first part contains the MIME entity that is signed; the second part contains the "detached signature" CMS SignedData object in which the encapContentInfo eContent field is absent.

この形式はクリア署名形式です。S/MIMEやCMSの処理機能を持たない受信者もメッセージを表示できます。[MIME-SECURE]で説明するmultipart/signed MIMEタイプを使用します。multipart/signed MIMEタイプは2つの部分から成ります。第1部分には署名対象のMIMEエンティティが含まれ、第2部分には、encapContentInfoのeContentフィールドが存在しない「分離署名」のCMS SignedDataオブジェクトが含まれます。

3.4.3.1. The application/pkcs7-signature MIME Type

3.4.3.1. application/pkcs7-signature MIMEタイプ

This MIME type always contains a CMS ContentInfo containing a single CMS object of type SignedData. The SignedData encapContentInfo eContent field MUST be absent. The signerInfos field contains the signatures for the MIME entity.

このMIMEタイプには、SignedData型のCMSオブジェクトを1つ含むCMS ContentInfoが常に含まれます。SignedDataのencapContentInfoのeContentフィールドは存在してはなりません (MUST)。signerInfosフィールドにはMIMEエンティティの署名が含まれます。

The file extension for signed-only messages using application/pkcs7- signature is ".p7s".

application/pkcs7-signatureを使う署名のみメッセージのファイル拡張子は".p7s"です。

3.4.3.2. Creating a multipart/signed Message

3.4.3.2. multipart/signedメッセージの作成

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. セクション3.1で説明した処理以外は行わずに、MIMEエンティティをmultipart/signedメッセージの第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オブジェクトに転送エンコーディングが適用され、application/pkcs7-signatureタイプのMIMEエンティティに挿入されます。

Step 5. The MIME entity of the application/pkcs7-signature is inserted into the second part of the multipart/signed entity.

ステップ5. application/pkcs7-signatureのMIMEエンティティが、multipart/signedエンティティの2番目の部分に挿入されます。

The multipart/signed Content type has two required parameters: the protocol parameter and the micalg parameter.

multipart/signedコンテンツタイプには、protocolパラメーターとmicalgパラメーターという2つの必須パラメーターがあります。

The protocol parameter MUST be "application/pkcs7-signature". Note that quotation marks are required around the protocol parameter because MIME requires that the "/" character in the parameter value MUST be quoted.

protocolパラメーターは"application/pkcs7-signature"でなければなりません (MUST)。パラメーター値内の"/"文字は引用符で囲まなければならない (MUST) ため、protocolパラメーターの値を引用符で囲む必要があります。これはMIMEの要件です。

The micalg parameter allows for one-pass processing when the signature is being verified. The value of the micalg parameter is dependent on the message digest algorithm(s) used in the calculation of the Message Integrity Check. If multiple message digest algorithms are used they MUST be separated by commas per [MIME-SECURE]. The values to be placed in the micalg parameter SHOULD be from the following: Algorithm Value used

micalgパラメーターを使うと、署名検証を1回の処理で行えます。micalgパラメーターの値は、Message Integrity Checkの計算に使ったメッセージダイジェストアルゴリズムによって決まります。複数のメッセージダイジェストアルゴリズムを使う場合は、[MIME-SECURE]に従ってカンマで区切らなければなりません (MUST)。micalgパラメーターには次の値を指定すべきです (SHOULD): Algorithm / Value used

   MD5         md5
   SHA-1       sha1
   SHA-256     sha256
   SHA-384     sha384
   SHA-512     sha512
   Any other   (defined separately in algorithm profile or "unknown"
                if not defined)

(Historical note: some early implementations of S/MIME emitted and expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize.

（歴史的注記: S/MIMEの初期実装の一部は、micalgパラメーターに"rsa-md5"と"rsa-sha1"を出力し、それらを受け付けていました。）受信エージェントは、認識できないmicalgパラメーター値を適切に処理すべきです (SHOULD)。

The SHA-256, SHA-384, and SHA-512 algorithms [FIPS180-2] are not currently recommended in S/MIME, and are included here for completeness.

SHA-256、SHA-384、SHA-512アルゴリズム[FIPS180-2]は、現在S/MIMEでは推奨されていませんが、情報を網羅するためここに記載しています。

3.4.3.3. Sample multipart/signed Message

3.4.3.3. サンプルマルチパート/署名メッセージ

       Content-Type: multipart/signed;
          protocol="application/pkcs7-signature";
          micalg=sha1; boundary=boundary42

       --boundary42
       Content-Type: text/plain

This is a clear-signed message.

       --boundary42
       Content-Type: application/pkcs7-signature; name=smime.p7s
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7s

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756

--boundary42--

The content that is digested (the first part of the multipart/signed) are the bytes:

multipart/signedの第1部分のうち、ダイジェスト対象となるバイト列は次のとおりです:

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

3.5. Creating an Compressed-only Message

3.5. 圧縮のみのメッセージの作成

This section describes the format for compressing a MIME entity. Please note that versions of S/MIME prior to 3.1 did not specify any use of CompressedData, and will not recognize it. The use of a capability to indicate the ability to receive CompressedData is described in [CMSCOMPR] and is the preferred method for compatibility.

このセクションでは、MIMEエンティティを圧縮する形式を説明します。S/MIME 3.1より前のバージョンではCompressedDataの使用が規定されておらず、認識もされないことに注意してください。CompressedDataを受信できる機能を示す方法は[CMSCOMPR]で説明されており、互換性のために推奨される方法です。

Step 1. The MIME entity to be compressed is prepared according to section 3.1.

ステップ1.圧縮されるMIMEエンティティは、セクション3.1に従って準備されています。

Step 2. The MIME entity and other required data is processed into a CMS object of type CompressedData.

ステップ2. MIMEエンティティとその他の必要なデータを、CompressedData型のCMSオブジェクトに処理します。

Step 3. The CompressedData object is wrapped in a CMS ContentInfo object.

ステップ3. CompressedDataオブジェクトをCMS ContentInfoオブジェクトで包みます。

Step 4. The ContentInfo object is inserted into an application/pkcs7-mime MIME entity.

ステップ4. ContentInfoオブジェクトは、application/pkcs7-mime MIMEエンティティに挿入されます。

The smime-type parameter for compressed-only messages is "compressed-data". The file extension for this type of message is ".p7z".

圧縮のみのメッセージのsmime-typeパラメーターは"compressed-data"です。このメッセージ形式のファイル拡張子は".p7z"です。

A sample message would be:

サンプルメッセージは次のとおりです。

       Content-Type: application/pkcs7-mime; smime-type=compressed-data;
            name=smime.p7z
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7z

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V

3.6. Multiple Operations

3.6. 複数の操作

The signed-only, encrypted-only, and compressed-only MIME formats can be nested. This works because these formats are all MIME entities that encapsulate other MIME entities.

署名のみ、暗号化のみ、圧縮のみのMIME形式は入れ子にできます。これらの形式はいずれも、他のMIMEエンティティをカプセル化するMIMEエンティティだからです。

An S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME within reasonable resource limits of the recipient computer.

S/MIME実装は、受信側コンピューターの妥当なリソース制限内で、任意の深さに入れ子になったS/MIMEを受信して処理できなければなりません (MUST)。

It is possible to apply any of the signing, encrypting, and compressing operations in any order. It is up to the implementer and the user to choose. When signing first, the signatories are then securely obscured by the enveloping. When enveloping first the signatories are exposed, but it is possible to verify signatures without removing the enveloping. This can be useful in an environment were automatic signature verification is desired, as no private key material is required to verify a signature.

署名、暗号化、圧縮の操作は、任意の順序で適用できます。順序は実装者とユーザーが選びます。最初に署名してから暗号化すると、暗号化によって署名者が外部から見えなくなります。最初に暗号化すると署名者は見えたままですが、暗号化を解除せずに署名を検証できます。これは、自動署名検証を行う環境で役立ちます。署名の検証に秘密鍵素材は必要ありません。

There are security ramifications to choosing whether to sign first or encrypt first. A recipient of a message that is encrypted and then signed can validate that the encrypted block was unaltered, but cannot determine any relationship between the signer and the unencrypted contents of the message. A recipient of a message that is signed-then-encrypted can assume that the signed message itself has not been altered, but that a careful attacker could have changed the unauthenticated portions of the encrypted message.

署名と暗号化のどちらを先に行うかには、セキュリティ上の影響があります。暗号化してから署名したメッセージの受信者は、暗号化ブロックが改変されていないことを検証できますが、署名者とメッセージの復号後の内容との関係は判断できません。署名してから暗号化したメッセージの受信者は、署名対象のメッセージ自体が改変されていないと判断できますが、注意深い攻撃者が暗号化メッセージの認証されていない部分を変更した可能性は残ります。

When using compression, keep the following guidelines in mind:

圧縮を使う場合は、次の指針に留意してください:

- Compression of binary encoded encrypted data is discouraged, since it will not yield significant compression. Base64 encrypted data could very well benefit, however. - If a lossy compression algorithm is used with signing, you will need to compress first, then sign.

- バイナリ符号化した暗号化データは、圧縮しても大きく縮小しないため、圧縮は推奨されません。ただし、Base64で符号化した暗号化データなら圧縮の効果が得られる場合があります。- 署名とともに非可逆圧縮を使う場合は、先に圧縮し、その後に署名する必要があります。

3.7. Creating a Certificate Management Message

3.7. 証明書管理メッセージの作成

The certificate management message or MIME entity is used to transport certificates and/or certificate revocation lists, such as in response to a registration request.

証明書管理メッセージまたはMIMEエンティティは、登録要求への応答などで、証明書および／または証明書失効リストを転送するために使用します。

Step 1. The certificates and/or certificate revocation lists are made available to the CMS generating process which creates a CMS object of type SignedData. The SignedData encapContentInfo eContent field MUST be absent and signerInfos field MUST be empty.

ステップ1. 証明書や証明書失効リストは、SignedDataタイプのCMSオブジェクトを作成するCMS生成プロセスに提供されます。SignedDataのencapContentInfoのeContentフィールドは存在してはならず (MUST)、signerInfosフィールドは空でなければなりません (MUST)。

Step 2. The SignedData object is wrapped in a CMS ContentInfo object.

ステップ2. SignedDataオブジェクトは、CMS ContentInfoオブジェクトにラップされています。

Step 3. The ContentInfo object is enclosed in an application/pkcs7- mime MIME entity.

ステップ3. ContentInfoオブジェクトは、application/pkcs7-MIME MIMEエンティティに囲まれています。

The smime-type parameter for a certificate management message is "certs-only". The file extension for this type of message is ".p7c".

証明書管理メッセージのsmime-typeパラメーターは"certs-only"です。このメッセージ形式のファイル拡張子は".p7c"です。

3.8. Registration Requests

3.8. 登録リクエスト

A sending agent that signs messages MUST have a certificate for the signature so that a receiving agent can verify the signature. There are many ways of getting certificates, such as through an exchange with a certificate authority, through a hardware token or diskette, and so on.

受信エージェントが署名を検証できるように、メッセージに署名する送信エージェントは、署名のための証明書を持っていなければなりません (MUST)。証明書を取得する方法には、認証局との交換、ハードウェアトークンやディスケットの利用など、多くの方法があります。

S/MIME v2 [SMIMEV2] specified a method for "registering" public keys with certificate authorities using an application/pkcs10 body part. Since that time, the IETF PKIX Working Group has developed other methods for requesting certificates. However, S/MIME v3.1 does not require a particular certificate request mechanism.

S/MIME V2 [SMIMEV2]は、application/pkcs10ボディパーツを使用して証明書当局に公開キーを「登録」する方法を指定しました。それ以来、IETF PKIXワーキンググループは、証明書を要求する他の方法を開発してきました。ただし、S/MIME V3.1では、特定の証明書要求メカニズムを必要としません。

3.9. Identifying an S/MIME Message

3.9. S/MIMEメッセージの識別

Because S/MIME takes into account interoperation in non-MIME environments, several different mechanisms are employed to carry the type information, and it becomes a bit difficult to identify S/MIME messages. The following table lists criteria for determining whether or not a message is an S/MIME message. A message is considered an S/MIME message if it matches any of the criteria listed below.

S/MIMEは非MIME環境との相互運用も考慮しているため、タイプ情報を伝えるために複数の方式を使います。そのためS/MIMEメッセージの識別はやや複雑です。次の表に、メッセージがS/MIMEメッセージかどうかを判断する基準を示します。以下のいずれかの基準に一致すれば、S/MIMEメッセージとみなします。

The file suffix in the table below comes from the "name" parameter in the content-type header, or the "filename" parameter on the content-disposition header. These parameters that give the file suffix are not listed below as part of the parameter section.

以下の表のファイル接尾辞は、Content-Typeヘッダーの"name"パラメーターまたはContent-Dispositionヘッダーの"filename"パラメーターから取得します。ファイル接尾辞を指定するこれらのパラメーターは、下のパラメーター欄には記載していません。

MIME type: application/pkcs7-mime parameters: any file suffix: any

   MIME type:   multipart/signed
   parameters:  protocol="application/pkcs7-signature"
   file suffix: any

MIME type: application/octet-stream parameters: any file suffix: p7m, p7s, p7c, p7z

4. Certificate Processing

4. 証明書処理

A receiving agent MUST provide some certificate retrieval mechanism in order to gain access to certificates for recipients of digital envelopes. This specification does not cover how S/MIME agents handle certificates, only what they do after a certificate has been validated or rejected. S/MIME certificate issues are covered in [CERT31].

受信エージェントは、デジタルエンベロープの受信者の証明書を取得できるよう、何らかの証明書取得機構を提供しなければなりません (MUST)。本仕様では、S/MIMEエージェントが証明書をどう扱うかではなく、証明書を検証または拒否した後の動作だけを扱います。S/MIME証明書の問題は[CERT31]で扱います。

At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message. Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval.

少なくともS/MIMEの初期導入時には、ユーザーエージェントが受信者に自動的にメッセージを送り、署名付き返信でその受信者の証明書を要求できます。送信エージェントと受信エージェントは、後で確実に取り出せるよう、通信相手の証明書をユーザーが「保存して保護」できる機構も提供すべきです (SHOULD)。

4.1. Key Pair Generation

4.1. キーペア生成

All generated key pairs MUST be generated from a good source of non-deterministic random input [RANDOM] and the private key MUST be protected in a secure fashion.

生成するすべての鍵ペアは、質の高い非決定的乱数入力[RANDOM]から生成しなければなりません (MUST)。秘密鍵は安全な方法で保護しなければなりません (MUST)。

If an S/MIME agent needs to generate an RSA key pair, then the S/MIME agent or some related administrative utility or function SHOULD generate RSA key pairs using the following guidelines. A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits. A user agent MUST NOT generate RSA key pairs less than 512 bits long. Creating keys longer than 1024 bits can cause some older S/MIME receiving agents to not be able to verify signatures, but gives better security and is therefore valuable. A receiving agent SHOULD be able to verify signatures with keys of any size over 512 bits. Some agents created in the United States have chosen to create 512 bit keys in order to get more advantageous export licenses. However, 512 bit keys are considered by many to be cryptographically insecure. Implementers SHOULD be aware that multiple (active) key pairs can be associated with a single individual. For example, one key pair can be used to support confidentiality, while a different key pair can be used for authentication.

S/MIMEエージェントがRSA鍵ペアを生成する必要がある場合、S/MIMEエージェントまたは関連する管理ユーティリティは、次の指針に従ってRSA鍵ペアを生成すべきです (SHOULD)。ユーザーエージェントは、鍵長を最低768ビットとしてRSA鍵ペアを生成すべきです (SHOULD)。ユーザーエージェントは、512ビット未満のRSA鍵ペアを生成してはなりません (MUST NOT)。1024ビットを超える鍵を作成すると一部の古いS/MIME受信エージェントが署名を検証できない場合がありますが、セキュリティが向上するため有用です。受信エージェントは、512ビットを超える任意の鍵長の署名を検証できるべきです (SHOULD)。米国で作成された一部のエージェントは、輸出ライセンスを有利にするため512ビット鍵を選びましたが、多くの人は512ビット鍵を暗号学的に安全でないと考えています。実装者は、1人の利用者に複数の（有効な）鍵ペアが関連付けられる場合があることを認識すべきです (SHOULD)。たとえば、一方を機密性の確保に、もう一方を認証に使用できます。

5. Security Considerations

5. セキュリティに関する考慮事項

40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of tripleDES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents SHOULD inform senders and recipients of the relative cryptographic strength of messages.

暗号学者の多くは40ビット暗号を弱いと見なしています。S/MIMEで弱い暗号を使っても、平文を送る場合と比べて実質的なセキュリティはほとんど得られません。一方、tripleDESの規定や、通信相手により強い暗号機能を通知する機能など、S/MIMEの他の機能を使えば、送信者は強い暗号を使うメッセージを作成できます。暗号を使わないことしか選べない場合を除き、弱い暗号の使用は推奨されません。可能な場合、送信エージェントと受信エージェントは、メッセージ間の暗号強度の違いを送信者と受信者に知らせるべきです (SHOULD)。

It is impossible for most software or people to estimate the value of a message. Further, it is impossible for most software or people to estimate the actual cost of decrypting a message that is encrypted with a key of a particular size. Further, it is quite difficult to determine the cost of a failed decryption if a recipient cannot decode a message. Thus, choosing between different key sizes (or choosing whether to just use plaintext) is also impossible. However, decisions based on these criteria are made all the time, and therefore this specification gives a framework for using those estimates in choosing algorithms.

ほとんどのソフトウェアや人は、メッセージの価値を見積もれません。また、特定の長さの鍵で暗号化されたメッセージを復号する実際のコストも見積もれません。受信者がメッセージを復号できない場合、復号失敗のコストを判断することも困難です。そのため、鍵長の選択や平文を使うかどうかの判断も容易ではありません。しかし、こうした基準に基づく判断は常に行われるため、本仕様ではアルゴリズム選択に見積もりを活用する枠組みを示します。

If a sending agent is sending the same message using different strengths of cryptography, an attacker watching the communications channel might be able to determine the contents of the strongly-encrypted message by decrypting the weakly-encrypted version. In other words, a sender SHOULD NOT send a copy of a message using weaker cryptography than they would use for the original of the message.

送信エージェントが同じメッセージを異なる暗号強度で送ると、通信経路を監視する攻撃者が弱い暗号化版を復号し、強い暗号化版の内容を知る可能性があります。つまり送信者は、元のメッセージに使う暗号より弱い暗号でそのコピーを送るべきではありません (SHOULD NOT)。

Modification of the ciphertext can go undetected if authentication is not also used, which is the case when sending EnvelopedData without wrapping it in SignedData or enclosing SignedData within it.

認証も使用しない場合、暗号文の改変が検出されない可能性があります。たとえば、SignedDataで包まず、またはEnvelopedData内にSignedDataを含めずにEnvelopedDataを送信する場合です。

See RFC 3218 [MMA] for more information about thwarting the adaptive chosen ciphertext vulnerability in PKCS #1 Version 1.5 implementations.

PKCS #1バージョン1.5の実装における適応的選択暗号文攻撃の脆弱性を防ぐ方法については、RFC 3218 [MMA]を参照してください。

In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. These methods are described in RFC 2785 [DHSUB].

状況によっては、大きな素数pの位数が素数である部分群でDiffie-Hellman鍵共有方式を使うと、「小部分群攻撃」と呼ばれる攻撃に対して脆弱です。ただし、これらの攻撃を防ぐ方法があり、RFC 2785 [DHSUB]で説明されています。

A. ASN.1 Module

A. ASN.1モジュール

SecureMimeMessageV3dot1
  { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS
-- Cryptographic Message Syntax
    SubjectKeyIdentifier, IssuerAndSerialNumber,
    RecipientKeyIdentifier
        FROM    CryptographicMessageSyntax
               { iso(1) member-body(2) us(840) rsadsi(113549)
                 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };

--  id-aa is the arc with all new authenticated and unauthenticated
--  attributes produced the by S/MIME Working Group

id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
        rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}

-- S/MIME Capabilities provides a method of broadcasting the symmetric
-- capabilities understood.  Algorithms SHOULD be ordered by
-- preference and grouped by type

smimeCapabilities OBJECT IDENTIFIER ::=
   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}

SMIMECapability ::= SEQUENCE {
   capabilityID OBJECT IDENTIFIER,
   parameters ANY DEFINED BY capabilityID OPTIONAL }

SMIMECapabilities ::= SEQUENCE OF SMIMECapability

-- Encryption Key Preference provides a method of broadcasting the
-- preferred encryption certificate.

id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}

SMIMEEncryptionKeyPreference ::= CHOICE {
   issuerAndSerialNumber   [0] IssuerAndSerialNumber,
   receipentKeyId          [1] RecipientKeyIdentifier,
   subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }

id-cap  OBJECT IDENTIFIER ::= { id-smime 11 }

-- The preferBinaryInside indicates an ability to receive messages
-- with binary encoding inside the CMS wrapper

id-cap-preferBinaryInside  OBJECT IDENTIFIER ::= { id-cap 1 }

-- The following list the OIDs to be used with S/MIME V3

- 次のリストS/MIME v3で使用するoids

-- Signature Algorithms Not Found in [CMSALG]
--
-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
--    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
--     2}
--
-- Other Signed Attributes
--
-- signingTime OBJECT IDENTIFIER ::=
--    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
--     5}
--    See [CMS] for a description of how to encode the attribute
--    value.

SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
--        (RC2 Key Length (number of bits))

END

終わり

B. References

B.参照

B.1. Normative References

B.1. 引用文献

[CERT31] Ramsdell, B., Ed., "S/MIME Version 3.1 Certificate Handling", RFC 3850, July 2004.

[CHARSETS] Character sets assigned by IANA. See http://www.iana.org/assignments/character-sets

[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.

[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.

[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.

[CMSCOMPR] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.

[CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.

[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.

[FIPS180-2] "Secure Hash Signature Standard (SHS)", National Institute of Standards and Technology (NIST). FIPS Publication 180-2.

[MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.

Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

[MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.

[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.

[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.

[X.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988.

B.2. Informative References

B.2. 参考引用

[DHSUB] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.

[MMA] Rescorla, E., "Preventing the Million Message Attack on Cryptographic Message Syntax", RFC 3218, January 2002.

[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.

[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.

[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.

C. Acknowledgements

C.謝辞

Many thanks go out to the other authors of the S/MIME Version 2 Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Lundblade and Lisa Repka.

S/MIMEバージョン2メッセージ仕様RFCの他の著者に感謝します：Steve Dusse、Paul Hoffman、Laurence Lundblade、Lisa Repka。

A number of the members of the S/MIME Working Group have also worked very hard and contributed to this document. Any list of people is doomed to omission, and for that I apologize. In alphabetical order, the following people stand out in my mind due to the fact that they made direct contributions to this document.

S/MIMEワーキンググループのメンバーの多くも、本書に多大な労力を費やし、貢献しました。ここにすべての人を挙げることはできず、その点をお詫びします。以下はアルファベット順で、本書に直接貢献した方々です:

Tony Capel Piers Chivers Dave Crocker Bill Flanigan Peter Gutmann Paul Hoffman Russ Housley William Ottaway John Pawling Jim Schaad

D. Editor's Address

D.編集者のアドレス

Blake Ramsdell Sendmail, Inc. 704 228th Ave NE #775 Sammamish, WA 98074

   EMail: blake@sendmail.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれる情報は「現状有姿」で提供されます。貢献者、その貢献者が代表する組織またはスポンサー組織（該当する場合）、Internet SocietyおよびInternet Engineering Task Forceは、本情報の利用が権利を侵害しないことの保証、商品性の黙示的保証、特定目的への適合性の黙示的保証を含め、明示または黙示を問わず、あらゆる保証を否認します。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書に記載された技術の実装または利用に関係すると主張される知的財産権その他の権利の有効性や範囲について立場を示しません。また、そのような権利に基づくライセンスが利用できるかどうかについても立場を示さず、権利を特定するため独自に調査したと表明するものでもありません。RFC文書に関する権利手続きはBCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に提出されたIPR開示の写し、利用可能にするライセンスの保証、および本仕様の実装者や利用者が独占的権利の使用許諾を得ようとした結果は、http://www.ietf.org/iprにあるIETFのオンラインIPRリポジトリで確認できます。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関係者に対し、本標準の実装に必要となる可能性のある技術を対象とする著作権、特許、特許出願、その他の独占的権利を把握した場合、IETFに知らせるよう求めています。情報はietf-ipr@ietf.org宛てにお送りください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。