NIST SP 800-49 日本語訳
英語タイトル : Federal S/MIME V3 Client Profile日本語タイトル : 連邦政府向けS/MIME V3クライアントプロファイル
公開日 : 2002-11-05
原文URL : https://csrc.nist.gov/pubs/sp/800/49/final
翻訳編集 : 自動生成（有志による非公式の日本語訳）, 原文取得日 : 2026-09-30, 訳文 : 360 / 360 ブロック
[要約] SP 800-49 は、電子メールを保護するS/MIME V3のクライアントについて、連邦政府向けのプロファイル要件を示します。基盤技術、S/MIMEメッセージの生成と受信処理、証明書の処理に加え、署名付き受領通知やセキュリティラベルなどの拡張セキュリティサービスと任意機能を扱います。調達担当者、実装者、ベンダー、S/MIME技術の仕様策定に関心を持つ人を対象とし、付録で一方向ハッシュや共通鍵暗号などのアルゴリズムスイートも示します。
NIST Special Publication 800-49
NIST特別出版物800-49
Federal S/MIME V3 Client Profile
連邦政府向けS/MIME V3クライアントプロファイル
［NIST のロゴ。公的な標章のため、この非公式サイトには掲載していません。原本 PDF を参照してください。］
C. Michael Chernick
C. Michael Chernick
C O M P U T E R S E C U R I T Y
コンピューターセキュリティ
November 2002
2002年11月
Federal S/MIME V3 Client
連邦政府向けS/MIME V3クライアント
NIST Special Publication 800-49
NIST特別出版物800-49
Profile
プロファイル
Recommendations of the National Institute of Standards and Technology
国立標準技術研究所の推奨事項
C. Michael Chernick
C. Michael Chernick
C O M P U T E R S E C U R I T Y
コンピューターセキュリティ
Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930
コンピューターセキュリティ部門 情報技術研究所 国立標準技術研究所 メリーランド州ゲイザースバーグ 20899-8930
November 2002
2002年11月
U.S. Department of Commerce Donald L. Evans, Secretary
米国商務省 ドナルド・L・エバンス長官
Technology Administration Phillip J. Bond, Under Secretary of Commerce for Technology
技術管理局 フィリップ・J・ボンド技術担当商務次官
National Institute of Standards and Technology Arden L. Bement, Jr., Director
国立標準技術研究所 アーデン・L・ベメント・ジュニア所長
Reports on Information Security Technology
情報セキュリティ技術に関する報告書
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations.
国立標準技術研究所（NIST）の情報技術研究所（ITL）は、国家の計測・標準インフラに技術的リーダーシップを提供することで、米国経済および公共の福祉を促進します。ITLは、情報技術の開発および生産的利用を推進するため、試験、試験方法、参照データ、概念実証の実装、および技術分析を開発します。ITLの責務には、連邦コンピューターシステム内の機微な非機密情報について、費用対効果に優れたセキュリティおよびプライバシーを実現するための技術的、物理的、運用的、管理的な標準およびガイドラインの策定が含まれます。特別出版物800シリーズは、コンピューターセキュリティに関するITLの研究、指針および普及活動、ならびに産業界、政府および学術機関との協力活動を報告します。
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.
実験手順または概念を適切に説明するため、本書では特定の商業組織、機器または材料を特定する場合があります。このような特定は、国立標準技術研究所による推奨または承認を意味するものではなく、当該組織、材料または機器が目的に対して必ずしも最良であることを意味するものでもありません。
National Institute of Standards and Technology Special Publication 800-46 Natl. Inst. Stand. Technol. Spec. Publ. 800-31, 26 pages (November 2002) CODEN: NSPUE2
国立標準技術研究所 特別出版物800-46 Natl. Inst. Stand. Technol. Spec. Publ. 800-31、26ページ（2002年11月） CODEN: NSPUE2
Acknowledgments
謝辞
NIST would like to thank the many people who assisted with the development of this profile. We are grateful for the support that we received from members of the Internet Engineering Task Force (IETF), IETF’s Public-Key Infrastructure Group (X.509) (PKIX) and S/MIME Working Groups. Special thanks are due to John Pawling, Jim Schaad, Russ Housley, Blake Ramsdell, and Tim Polk.
NISTは、本プロファイルの策定に協力した多くの方々に感謝します。Internet Engineering Task Force（IETF）、IETFのPublic-Key Infrastructure Group（X.509）（PKIX）およびS/MIMEワーキンググループのメンバーからいただいた支援に感謝します。John Pawling、Jim Schaad、Russ Housley、Blake RamsdellおよびTim Polk各氏に特に謝意を表します。
Executive Summary to the Federal S/MIME V3 Client Profile
連邦政府向けS/MIME V3クライアントプロファイルの概要
(For Procurement Officials, Implementers, Vendors and Others Interested in Specifying S/MIME Technology)
（調達担当者、実装者、ベンダー、およびS/MIME技術の仕様策定に関心を持つその他の方々向け）
S/MIME (Secure / Multipurpose Internet Mail Extensions) is a set of specifications for securing electronic mail. S/MIME is based upon the widely used MIME standard [MIME] and describes a protocol for adding cryptographic security services through MIME encapsulation of digitally signed and encrypted objects. The basic security services offered by S/MIME are authentication, non-repudiation of origin, message integrity, and message privacy. Optional security services include signed receipts, security labels, secure mailing lists, and an extended method of identifying the signer’s certificate(s).
S/MIME（Secure / Multipurpose Internet Mail Extensions）は、電子メールを保護するための一連の仕様です。S/MIMEは広く使用されているMIME標準 [MIME] に基づき、デジタル署名および暗号化されたオブジェクトをMIMEにカプセル化して暗号セキュリティサービスを追加するプロトコルを記述します。S/MIMEが提供する基本的なセキュリティサービスは、認証、送信元の否認防止、メッセージ完全性およびメッセージ機密性です。任意のセキュリティサービスには、署名付き受領通知、セキュリティラベル、安全なメーリングリスト、および署名者の証明書を識別する拡張方式が含まれます。
To understand S/MIME it is useful to understand some of the history of Internet e-mail. In the past twenty-five years or so, Internet e-mail has evolved from a simple text-based (ASCII) transfer of messages designed for researchers into a more sophisticated messaging system capable of communicating a wealth of digital information (e.g., photographic images, computer files, sound clips, cinema) to many millions of people around the world.
S/MIMEを理解するには、インターネット電子メールの歴史を知るとよいです。過去約25年間に、インターネット電子メールは、研究者向けに設計された単純なテキストベース（ASCII）のメッセージ転送から、世界中の何百万もの人々に多様なデジタル情報（写真画像、コンピューターファイル、音声クリップ、映像など）を伝達できる、より高度なメッセージングシステムへと進化しました。
Internet e-mail was designed for a small community of trusted researchers (primarily at university and government sites) for exchanging text-based messages, and thus security was not a goal in its design. Over the years many deficiencies in Internet e-mail have been overcome to a certain extent through the use of a technology called Multipurpose Internet Mail Extensions (MIME). Employing MIME for messaging allows the use of multiple-text effects (e.g., bold, italic, various font sizes, and colors) as well as the transfer of digital information. MIME by itself also does not address security issues. However, a set of security features has been developed and added to MIME to form what is known as S/MIME (Secure MIME).
インターネット電子メールは、信頼できる小規模な研究者コミュニティ（主に大学および政府機関）内でテキストメッセージを交換するために設計されたため、その設計ではセキュリティは目標とされていませんでした。長年にわたり、Multipurpose Internet Mail Extensions（MIME）と呼ばれる技術を使用して、インターネット電子メールの多くの欠点がある程度解消されてきました。メッセージングにMIMEを用いると、複数のテキスト表現（太字、斜体、さまざまなフォントサイズや色など）を使用でき、デジタル情報も転送できます。MIME自体はセキュリティ上の問題に対処しません。しかし、MIMEに一連のセキュリティ機能を追加して、S/MIME（Secure MIME）が形成されました。
S/MIME adds features to e-mail messaging including privacy (using encryption), authentication of sending party (using digital signatures), integrity (non-alteration of messages), etc. S/MIME V3 is the latest version of S/MIME and is supported in whole or part by several vendors with “Commercial-Off-The-Shelf” (COTS) products.
S/MIMEは、暗号化による機密性、デジタル署名による送信者の認証、完全性（メッセージが改変されていないこと）などの機能を電子メールメッセージングに追加します。S/MIME V3はS/MIMEの最新バージョンであり、複数のベンダーの「市販製品」（COTS）で全部または一部がサポートされています。
Because S/MIME still uses the same extant Internet e-mail technology that has been widely deployed for many years, it is not necessary to modify or replace e-mail “servers” to accommodate S/MIME. Rather S/MIME functionality may be added to e-mail “client” software. By not disturbing the underlying e-mail server/message transfer system, S/MIME allows gradual migration from non-secure to secure e-mail messaging, rather than requiring a large, possibly abrupt change in technology.
S/MIMEは長年広く導入されている既存のインターネット電子メール技術をそのまま使用するため、S/MIMEに対応するために電子メール「サーバー」を変更または置換する必要はありません。むしろ、S/MIME機能は電子メール「クライアント」ソフトウェアに追加できます。基盤となる電子メールサーバー／メッセージ転送システムに手を加えず、S/MIMEは大規模で突然の技術変更を必要とせずに、非セキュアな電子メールからセキュアな電子メールへの段階的な移行を可能にします。
Like other services and protocols used by the Internet community, S/MIME has been under development for many years, with the main components specified by the Internet Engineering Task Force (IETF), a technical body that issues specifications that serve as standards for vendor implementation. These specifications are known as "Request for Comments"1 (RFCs). The IETF RFCs for S/MIME reference important standards issued by the International Organization for Standardization (ISO) and the International Telecommunication Union (ITU). In addition, the U.S. National Institute of Standards and Technology (NIST) has issued certain Federal Information Processing Standards (FIPS) that are used to specify requirements for cryptographic algorithms and related hardware/software modules used by S/MIME. Thus, implementers and users must adhere to a very large set of “standards.”
インターネットコミュニティが使用する他のサービスやプロトコルと同様に、S/MIMEも長年にわたって開発されてきました。主な構成要素は、ベンダー実装の標準となる仕様を発行する技術団体であるInternet Engineering Task Force（IETF）が規定しています。これらの仕様は「Request for Comments」1（RFC）として知られます。S/MIMEに関するIETF RFCは、国際標準化機構（ISO）および国際電気通信連合（ITU）が発行する重要な標準を参照しています。さらに、米国国立標準技術研究所（NIST）は、S/MIMEで使用される暗号アルゴリズムおよび関連するハードウェア／ソフトウェアモジュールの要件を規定する連邦情報処理標準（FIPS）を発行しています。したがって、実装者および利用者は非常に多くの「標準」に従わなければなりません。
Furthermore, because standards developers allow many options within communications systems, even if all standards are rigidly adhered to, interoperability may not be possible due to differing choices of options selected by different vendors. For example, if vendor A chooses to implement signed receipts and vendor B chooses not to, then the signed receipts requested by the user of vendor A's products will never be sent by vendor B's product although neither implementation violates the standards.
さらに、標準策定者は通信システム内で多くの選択肢を認めているため、すべての標準を厳格に遵守していても、ベンダーごとの選択肢の違いによって相互運用できない場合があります。たとえば、ベンダーAが署名付き受領通知を実装し、ベンダーBが実装しない場合、どちらの実装も標準に違反していないにもかかわらず、ベンダーA製品の利用者が要求した署名付き受領通知はベンダーB製品から送信されません。
To help assure that S/MIME products can interoperate and meet the e-mail security needs of federal agencies both with respect to security features, and adequate cryptographic algorithms, NIST has developed this Federal S/MIME V3 Client Profile. This profile states requirements for implementing sets of cryptographic algorithm suites specified elsewhere by the standards development organizations. The profile specifies a set of e-mail security features (e.g., encrypted e-mail, signed receipts) that are mandatory to be implemented. In the definition of this Profile, NIST’s intention is never to violate underlying S/MIME standards, but rather to provide additional specificity within the standards.
S/MIME製品の相互運用性を確保し、セキュリティ機能および十分な暗号アルゴリズムの両面で連邦機関の電子メールセキュリティ需要を満たすため、NISTは本連邦政府向けS/MIME V3クライアントプロファイルを策定しました。本プロファイルは、標準化団体が別途規定する暗号アルゴリズムスイート群の実装要件を定めます。また、実装が必須となる電子メールセキュリティ機能（暗号化電子メール、署名付き受領通知など）を規定します。本プロファイルの定義にあたり、NISTは基礎となるS/MIME標準に違反せず、標準の範囲内で仕様をより具体化することを意図しています。
While NIST believes that use of this profile will help assure interoperability of the near term secure e-mail products, NIST anticipates that future revisions of the profile will be required to reflect new cryptographic algorithms and related attacks, new underlying S/MIME standards, and new e-mail security features required by federal agencies.
NISTは、本プロファイルの使用によって近い将来のセキュア電子メール製品の相互運用性が確保されると考えていますが、新しい暗号アルゴリズムおよび関連する攻撃、基礎となる新たなS/MIME標準、ならびに連邦機関が必要とする新たな電子メールセキュリティ機能を反映するため、将来、本プロファイルの改訂が必要になると見込んでいます。
The use of S/MIME requires the establishment of a Public Key Infrastructure (PKI) to support each sender and recipient of S/MIME messages. While the details of PKI are out of scope for this document, it is important to note that PKI is used to provide mechanisms to establish the identity of S/MIME users (known as authentication) and to provide for digital signatures, confidentiality, non-repudiation of sender, etc. X.509 Certificates are used to bind an entity’s identity and public key for secure operations for S/MIME and other PKI-enabled secure applications. For a further understanding of PKI, see [Kuhn01], [Housley01], or [Adams00] in the References clause.
S/MIMEを使用するには、S/MIMEメッセージの各送信者および受信者を支援する公開鍵基盤（PKI）を確立する必要があります。PKIの詳細は本書の適用範囲外ですが、PKIはS/MIME利用者の身元を確立する仕組み（認証として知られる）を提供し、デジタル署名、機密性、送信者の否認防止などを実現するために使用される点に留意することが重要です。X.509証明書は、S/MIMEおよびその他のPKI対応セキュアアプリケーションにおける安全な処理のため、主体の識別情報と公開鍵を結び付けます。PKIをさらに理解するには、参考文献節の[Kuhn01]、[Housley01]または[Adams00]を参照します。
Summary of E-mail Security Features Mandated by the Federal S/MIME V3 Client Profile
連邦政府向けS/MIME V3クライアントプロファイルで義務付けられる電子メールセキュリティ機能の概要
| Feature | Requirement |
|---|---|
| Signed Messages | Send and receive |
| Encrypted Messages | Send and receive |
| Signed and Encrypted Messages | Send and receive |
| Signed Receipt Processing | Request, send, and process signed receipts |
| Receipt of Messages from Secure Mail List Agents | Process messages from secure mail list agents (includes suppressing of receipts as required and non-disclosure of list recipients as required) |
| Cryptographic Modules | FIPS 140-1 or FIPS 140-2, Security Requirements for Cryptographic Modules2 |
| Cryptographic Algorithm Suite 1 (ALS1) | RSA for digital signature [RFC2313] with SHA-1 hash algorithm [FIPS180-1], RSA for key transport [RFC2313], Triple-DES [FIPS46-3] for content encryption (RSA Key Sizes >= 1024 bits) |
| Cryptographic Algorithm Suite 2 (ALS2) | DSA for digital signature [FIPS186-2] with SHA-1 hash algorithm [FIPS180-1], RSA [RFC2313] for key transport, Triple-DES [FIPS46-3] for content encryption (DSA Key Size =1024 bits) (RSA Key Size >= 1024 bits) |
| Public Key Infrastructure (PKI) | Senders/receivers require valid X.509 certificates (Conformance to Federal PKI X.509 Certificate and CRL Extensions Profile required) |
| 機能 | 要件 |
|---|---|
| 署名付きメッセージ | 送信および受信 |
| 暗号化メッセージ | 送信および受信 |
| 署名付きおよび暗号化されたメッセージ | 送信および受信 |
| 署名付き受領通知処理 | 署名付き受領通知の要求、送信、および処理 |
| セキュアメーリングリストエージェントからのメッセージ受信 | セキュアメーリングリストエージェントからのメッセージを処理する（必要に応じた受領通知の抑止、および必要に応じたリスト受信者の非開示を含む） |
| 暗号モジュール | FIPS 140-1またはFIPS 140-2「暗号モジュールのセキュリティ要件」2 |
| 暗号アルゴリズムスイート1（ALS1） | デジタル署名用RSA [RFC2313]とSHA-1ハッシュアルゴリズム [FIPS180-1]、鍵転送用RSA [RFC2313]、コンテンツ暗号化用Triple-DES [FIPS46-3]（RSA鍵サイズ >= 1024ビット） |
| 暗号アルゴリズムスイート2（ALS2） | デジタル署名用DSA [FIPS186-2]とSHA-1ハッシュアルゴリズム [FIPS180-1]、鍵転送用RSA [RFC2313]、コンテンツ暗号化用Triple-DES [FIPS46-3]（DSA鍵サイズ = 1024ビット）（RSA鍵サイズ >= 1024ビット） |
| 公開鍵基盤（PKI） | 送信者／受信者は有効なX |
Note that compliant implementations can generate “clear” signed messages using RSA or DSA signature algorithms. (“Clear” signed messages can be read by non S/MIME-enabled clients, although signatures cannot be automatically processed and verified by such clients.) S/MIME signed messages may include the time that signatures were generated as well as the sender’s PKI certificates. The sender’s PKI certificates (also known as X.509 certificates) can be used to verify the sender’s identity and help to enable other security services.
準拠する実装は、RSAまたはDSA署名アルゴリズムを使用して「クリア」署名付きメッセージを生成できます。（「クリア」署名付きメッセージは、S/MIME非対応クライアントでも読むことができますが、そのようなクライアントでは署名を自動的に処理・検証できません。）S/MIME署名付きメッセージには、署名が生成された時刻と送信者のPKI証明書を含めてもよいです。送信者のPKI証明書（X.509証明書とも呼ばれる）は、送信者の身元検証に使用でき、その他のセキュリティサービスの実現にも役立ちます。
Compliant implementations process both “clear” and “opaque” signed messages. (“Opaque” signed messages are encoded such that the recipient requires an S/MIME-enabled e-mail client to automatically read the message.) Each implementation uses the Lightweight Directory Access Protocol (LDAP) to obtain certificates and certificate revocation lists (CRLs) and checks that the proper fields within each certificate match the sender’s name.
準拠する実装は、「クリア」および「オペーク」の両方の署名付きメッセージを処理します。（「オペーク」署名付きメッセージは、受信者がメッセージを自動的に読むためにS/MIME対応電子メールクライアントを必要とする形式で符号化されます。）各実装は、証明書および証明書失効リスト（CRL）を取得するためにLightweight Directory Access Protocol（LDAP）を使用し、各証明書内の適切なフィールドが送信者名と一致することを確認します。
Compliant implementations must be able to encrypt messages for one or more recipients.
準拠する実装は、1人以上の受信者向けにメッセージを暗号化できなければなりません。
Optional Services
任意サービス
The profile identifies three optional cryptographic algorithm suites. These are desirable to implement but not mandatory. These suites are:
本プロファイルは、3つの任意の暗号アルゴリズムスイートを特定します。これらの実装が望ましいですが、必須ではありません。スイートは次のとおりである:
ALS3: {RSA [RFC 2313] for digital signature with SHA-1 hash algorithm [FIPS180-1], RSA [RFC 2313] for key transport, AES [FIPS197] for content encryption}
ALS3: {デジタル署名用RSA [RFC 2313] とSHA-1ハッシュアルゴリズム [FIPS180-1]、鍵転送用RSA [RFC 2313]、コンテンツ暗号化用AES [FIPS197]}
ALS4: {DSA for digital signature [FIPS186-2] with SHA-1 hash algorithm [FIPS180-1], Diffie-Hellman [RFC2631] for key agreement, Triple-DES for content encryption [FIPS46-3].}
ALS4: {デジタル署名用DSA [FIPS186-2] とSHA-1ハッシュアルゴリズム [FIPS180-1]、鍵合意用Diffie-Hellman [RFC2631]、コンテンツ暗号化用Triple-DES [FIPS46-3]。}
ALS5: {DSA for digital signature [FIPS186-2] with SHA-256 hash algorithm [FIPS180-2], Diffie-Hellman [RFC2631] for key agreement, AES [FIPS197] for content encryption}
ALS5: {デジタル署名用DSA [FIPS186-2] とSHA-256ハッシュアルゴリズム [FIPS180-2]、鍵合意用Diffie-Hellman [RFC2631]、コンテンツ暗号化用AES [FIPS197]}
Note: Newer versions of DSA are anticipated with support for key sizes greater than 1024 bits. New standards for D-H and AES usage are anticipated to require the use of the SHA-256 hash algorithm. The SHA-256 algorithm is now available. [FIPS180-2]
注: 1024ビットを超える鍵サイズをサポートする新しいバージョンのDSAが予定されています。D-HおよびAESの使用に関する新しい標準では、SHA-256ハッシュアルゴリズムの使用が求められる見込みです。SHA-256アルゴリズムは現在利用可能です。[FIPS180-2]
Optional services in this profile include the ability to send and process e-mail with security labels (as defined in the S/MIME V3 standards [RFC2634]). Another optional service is the ability to securely bind sender’s certificates to their signatures through the signing certificate attribute (as defined in [RFC2634]).
本プロファイルの任意サービスには、（S/MIME V3標準 [RFC2634] で定義される）セキュリティラベル付き電子メールの送信および処理機能が含まれます。もう1つの任意サービスは、署名証明書属性（[RFC2634]で定義）を通じて、送信者の証明書をその署名に安全に結び付ける機能です。
Mail list agent processing (also defined in [RFC2634]) is out-of-scope (i.e., will not be tested for conformance) with respect to this protocol. However, S/MIME-enabled e-mail client software MUST be able to properly process messages from secure mail list agents.
メーリングリストエージェントの処理（これも[RFC2634]で定義）は、本プロトコルに関する適合性評価の対象外（すなわち、適合性試験を実施しない）です。ただし、S/MIME対応電子メールクライアントソフトウェアは、セキュアメーリングリストエージェントからのメッセージを適切に処理できなければなりません（MUST）。
Table of Contents
目次
1 Introduction
1 はじめに
S/MIME (Secure / Multipurpose Internet Mail Extensions) is a set of specifications for securing electronic mail. S/MIME is based upon the widely used MIME standard [MIME] and describes a protocol for adding cryptographic security services through MIME encapsulation of digitally signed and encrypted objects. The basic security services offered by S/MIME are authentication, non-repudiation of origin, message integrity, and message privacy. Optional security services include signed receipts, security labels, secure mailing lists, and an extended method of identifying the signer’s certificate(s).
S/MIME（Secure / Multipurpose Internet Mail Extensions）は、電子メールを保護するための一連の仕様です。S/MIMEは広く使用されているMIME標準[MIME]に基づき、デジタル署名および暗号化されたオブジェクトをMIMEでカプセル化して暗号セキュリティサービスを追加するプロトコルを記述します。S/MIMEが提供する基本的なセキュリティサービスは、認証、送信元否認防止、メッセージ完全性、メッセージ機密性です。任意のセキュリティサービスには、署名付き受領通知、セキュリティラベル、安全なメーリングリスト、署名者の証明書を識別する拡張方式が含まれます。
S/MIME Version 3 is the latest version of S/MIME. Version 3 is specified in IETF RFCs 2630 through 2634 ([RFC2630], [RFC2631], [RFC2632], [RFC2633], and [RFC2634]).
S/MIME Version 3はS/MIMEの最新バージョンです。Version 3はIETF RFC 2630から2634（[RFC2630]、[RFC2631]、[RFC2632]、[RFC2633]、[RFC2634]）で規定されています。
The S/MIME specifications were designed to promote interoperable secure electronic mail, such that two compliant implementations would be able to communicate securely with one another. However, implementations may support different optional services, and the specifications may unintentionally allow multiple interpretations. As a result, different implementations of S/MIME may not be fully interoperable or provide the desired level of security.
S/MIME仕様は、相互運用可能な安全な電子メールを促進するよう設計されており、適合する二つの実装間で安全に通信できることを意図しています。ただし、実装ごとに異なる任意サービスをサポートする場合があり、仕様が意図せず複数の解釈を許すこともあります。その結果、異なるS/MIME実装は完全には相互運用できなかったり、望ましいセキュリティレベルを提供できなかったりする場合があります。
The S/MIME specifications rely on cryptographic mechanisms and public key infrastructures (PKI) to provide security services. If the cryptographic and PKI components that are used to support the S/MIME implementation are sufficiently robust, users can obtain additional assurance that sufficiently strong cryptographic algorithms are used, and that procedures are in place to protect sensitive information.
S/MIME仕様は、セキュリティサービスを提供するため、暗号メカニズムと公開鍵基盤（PKI）に依存します。S/MIME実装を支援する暗号およびPKIコンポーネントが十分に堅牢であれば、十分に強度の高い暗号アルゴリズムが使われ、機微情報を保護する手順が整備されているという追加の保証を利用者が得られます。
Conformance to this profile helps to assure that S/MIME implementations will be able to interoperate and provide reasonable assurance to users.
本プロファイルに適合することで、S/MIME実装の相互運用性が確保され、利用者に合理的な保証を提供できます。
The National Institute of Standards and Technology (NIST), Information Technology Laboratory, Computer Security Division, has developed this S/MIME client profile as guidance in the development and procurement of commercial-off-the-shelf (COTS) S/MIME-compliant products. This profile document identifies requirements for a secure and interoperable S/MIME V3 client implementation. NIST is developing tests and testing tools to determine the level of conformance of an S/MIME V3 client implementation with this profile.
米国国立標準技術研究所（NIST）情報技術研究所コンピューターセキュリティ部門は、市販既製品（COTS）のS/MIME適合製品の開発および調達を支援するガイダンスとして、本S/MIMEクライアントプロファイルを策定しました。本プロファイル文書は、安全で相互運用可能なS/MIME V3クライアント実装の要件を特定します。NISTは、S/MIME V3クライアント実装の本プロファイルへの適合レベルを判定するための試験および試験ツールを開発しています。
This profile does not address requirements for network infrastructure components that implement S/MIME V3, such as mail list agents (MLAs) and secure mail gateways (e.g., security guards). Such systems will have significant overlap but will have additional requirements specific to their function.
本プロファイルは、メーリングリストエージェント（MLA）やセキュアメールゲートウェイ（例：セキュリティガード）など、S/MIME V3を実装するネットワーク基盤コンポーネントの要件は扱いません。こうしたシステムには大幅な共通点がありますが、その機能に固有の追加要件もあります。
The remainder of this document is organized into four principal sections: (a) S/MIME Profile requirements; (b) Support for Enhanced Security Services (ESS); (c) Optional Features and Notes on Testing; and (d) References. In addition, there is a non-Normative Appendix on Cryptographic Algorithms. The profile requirements describe the minimum functionality required to support secure and interoperable S/MIME client implementations. The support for ESS section discusses requirements for ESS conformance. The optional features and notes on testing section specifies desirable, but optional features for S/MIME client implementations as well as useful notes for testing. These features will be useful to “power” users, but fall outside the core services required to support mainstream S/MIME users. The references section provides current URL as well as document titles when documents are on-line. The non-normative appendix on cryptographic algorithms provides guidance on cryptographic algorithms.
本書の残りは、主に次の四つの節で構成されます。(a) S/MIMEプロファイル要件、(b) 拡張セキュリティサービス（ESS）のサポート、(c) 任意機能および試験に関する注記、(d) 参考文献。また、暗号アルゴリズムに関する規範外の付録があります。プロファイル要件では、安全で相互運用可能なS/MIMEクライアント実装を支援するために必要な最低限の機能を記述します。ESSのサポートについては、ESSへの適合要件を論じます。任意機能および試験に関する注記の節では、S/MIMEクライアント実装に望ましいが任意である機能と、試験に役立つ注記を示します。これらの機能は「パワーユーザー」には有用ですが、一般的なS/MIME利用者に必要な中核サービスの範囲外です。参考文献の節には、オンライン文書について最新のURLと文書タイトルを記載します。暗号アルゴリズムに関する規範外の付録では、暗号アルゴリズムのガイダンスを示します。
2 S/MIME Profile Requirements
2 S/MIMEプロファイル要件
Important S/MIME interoperability and security features are identified in this section. First, underlying technologies are examined, including cryptography, public key infrastructure (PKI), and formatting of cryptographically protected data. The following subsection describes requirements in these areas. Using these technologies, S/MIME clients perform two fundamental operations: they generate electronic mail messages and process electronic mail messages. The second and third sections describe the minimum functionality for S/MIME message generation and reception, respectively.
本節では、S/MIMEの相互運用性とセキュリティに重要な機能を特定します。まず、暗号、公開鍵基盤（PKI）、暗号保護データの形式などの基盤技術を検討し、続く小節でこれらの領域の要件を説明します。これらの技術を用いて、S/MIMEクライアントは電子メールメッセージの生成と処理という二つの基本操作を行います。メッセージ生成とメッセージ受信の各節では、それぞれS/MIMEメッセージの生成と受信に必要な最低限の機能を説明します。
Conformant implementations MUST be able to generate and process signed, encrypted, and signed and encrypted messages as detailed in the paragraphs that follow. Conformant implementations MUST be able to support all of the mandatory clauses of the IETF RFCs 2630, 2632, and 2633 with the exception that implementation of RFC 2631 Ephemeral-Static Diffie-Hellman Key Agreement [RFC2631] algorithm mandated in [RFC2630] is NOT required by this Profile. However, implementation of the Ephemeral-Static Diffie-Hellman Key Agreement algorithm in RFC 2631 is recommended. The terms “MUST,” “SHOULD,” and “MAY” are used as defined in RFC 2119 [MUSTSHOULD].
適合実装は、以下の段落で詳述する署名付き、暗号化済み、および署名付きかつ暗号化済みのメッセージを生成・処理できなければなりません（MUST）。適合実装は、IETF RFC 2630、2632、2633の必須条項をすべてサポートできなければなりません（MUST）。ただし、RFC 2631の一時・静的Diffie-Hellman鍵合意[RFC2631]アルゴリズム（[RFC2630]で必須とされる）の実装は、本プロファイルでは必須ではありません（NOT required）。ただし、RFC 2631の一時・静的Diffie-Hellman鍵合意アルゴリズムの実装を推奨します。「MUST」「SHOULD」「MAY」はRFC 2119 [MUSTSHOULD]で定義された意味で用います。
Conformance to this profile also assumes implementations of Federal Information Processing Standards (FIPS) approved cryptographic algorithms as specified in Clause 2.1.1.
本プロファイルへの適合は、2.1.1項で規定する連邦情報処理標準（FIPS）承認済み暗号アルゴリズムの実装も前提とします。
2.1 Fundamental Technologies
2.1 基盤技術
S/MIME relies on four fundamental technologies to format and protect electronic mail messages. These fundamental technologies are cryptographic algorithms, public key infrastructure (PKI), the cryptographic message syntax (CMS) data format, and MIME. Correct implementation of these mechanisms is essential to the security and interoperability of every S/MIME client. While these technologies will not be tested in isolation, they will be tested indirectly.
S/MIMEは電子メールメッセージを形式化し保護するため、四つの基盤技術に依存します。これらは暗号アルゴリズム、公開鍵基盤（PKI）、暗号メッセージ構文（CMS）データ形式、MIMEです。これらのメカニズムを正しく実装することは、すべてのS/MIMEクライアントのセキュリティと相互運用性に不可欠です。これらの技術を単独で試験することはありませんが、間接的には試験します。
However, not all features available through these technologies are required for S/MIME. To that end, we describe the features that are required by this profile.
ただし、これらの技術で利用できるすべての機能がS/MIMEで必要なわけではありません。そのため、本プロファイルが要求する機能を以下に記述します。
2.1.1 Cryptographic Algorithm Suite Conformance
2.1.1 暗号アルゴリズムスイートへの適合
To help ensure that cryptographic functions are correctly implemented, software modules implementing cryptographic functions MUST conform to either FIPS 140-1, or FIPS 140-2, Security Requirements For Cryptographic Modules [FIPS140-1] [FIPS140-2]3.
暗号機能が正しく実装されるよう、暗号機能を実装するソフトウェアモジュールは、FIPS 140-1またはFIPS 140-2「暗号モジュールのセキュリティ要件」([FIPS140-1]、[FIPS140-2])3のいずれかに適合しなければなりません（MUST）。
2.1.1.1 Mandatory to Implement Algorithm Suites
2.1.1.1 実装必須のアルゴリズムスイート
Conforming Federal S/MIME Profile implementations MUST support the following suites of cryptographic algorithms: ALS1: {RSA for digital signature [RFC2313] with SHA-1 hash algorithm [FIPS180-1], RSA for key transport [RFC2313], Triple-DES [FIPS46-3] for content encryption} Conforming implementations MUST support a RSA key size of at least 1024 bits. For Triple-DES, when generating messages at least two independent keys MUST be supported using the Cipher Block Chaining (CBC) Mode. This algorithm is also known as DES EDE3 CBC.
連邦S/MIMEプロファイルに準拠する実装は、次の暗号アルゴリズムスイートをサポートしなければなりません（MUST）。ALS1：{デジタル署名用RSA [RFC2313]とSHA-1ハッシュアルゴリズム [FIPS180-1]、鍵転送用RSA [RFC2313]、コンテンツ暗号化用Triple-DES [FIPS46-3]}。準拠実装は少なくとも1024ビットのRSA鍵サイズをサポートしなければなりません（MUST）。Triple-DESでは、メッセージを生成する際、Cipher Block Chaining（CBC）モードで少なくとも独立した2つの鍵をサポートしなければなりません（MUST）。このアルゴリズムはDES EDE3 CBCとも呼ばれます。
ALS2: {DSA for digital signature [FIPS186-2] with SHA-1 hash algorithm [FIPS180-1], RSA [RFC2313] for key transport, Triple-DES [FIPS46-3] for content encryption} Conforming implementations MUST support a DSA key size of 1024 bits.
ALS2：{デジタル署名用DSA [FIPS186-2]とSHA-1ハッシュアルゴリズム[FIPS180-1]、鍵転送用RSA [RFC2313]、コンテンツ暗号化用Triple-DES [FIPS46-3]} 適合実装は、1024ビットのDSA鍵サイズをサポートしなければなりません（MUST）。
This profile requires that implementations MUST be able to verify signatures on certificates and messages using either of the above algorithm suites. However for message generation only one of these algorithm suites MUST be supported. This implies that both the RSA digital signature and DSA algorithms MUST be supported for message verification, but only one of these algorithms MUST be supported for message generation. However, implementations SHOULD support both signature algorithms for message generation.
本プロファイルでは、実装が上記のどちらのアルゴリズムスイートを用いても証明書およびメッセージの署名を検証できなければなりません（MUST）。ただし、メッセージ生成では、これらのアルゴリズムスイートのうち一つのサポートのみが必須（MUST）です。つまり、メッセージ検証ではRSAデジタル署名アルゴリズムとDSAの両方をサポートしなければならない（MUST）が、メッセージ生成ではこれらのアルゴリズムのうち一つのサポートのみが必須（MUST）です。ただし、メッセージ生成について両方の署名アルゴリズムをサポートすべきです（SHOULD）。
2.1.1.2 Recommended Algorithm Suites
2.1.1.2 推奨アルゴリズムスイート
In addition to supporting ALS1 or ALS2, conforming implementations SHOULD support the following additional algorithm suites:
ALS1またはALS2のサポートに加え、適合実装は次の追加アルゴリズムスイートをサポートすべきです（SHOULD）。
ALS3: {RSA [RFC 2313] for digital signature with SHA-1 hash algorithm [FIPS180-1], RSA [RFC 2313] for key transport, Advanced Encryption Standard [FIPS197] for content encryption}
ALS3：{デジタル署名用RSA [RFC 2313]とSHA-1ハッシュアルゴリズム[FIPS180-1]、鍵転送用RSA [RFC 2313]、コンテンツ暗号化用Advanced Encryption Standard [FIPS197]}
ALS4: {DSA for digital signature [FIPS186-2] with SHA-1 hash algorithm [FIPS180-1], Diffie-Hellman [RFC2631] for key agreement, Triple-DES for content encryption [FIPS46-3].}
ALS4：{デジタル署名用DSA [FIPS186-2]とSHA-1ハッシュアルゴリズム[FIPS180-1]、鍵合意用Diffie-Hellman [RFC2631]、コンテンツ暗号化用Triple-DES [FIPS46-3]。}
ALS5: {DSA for digital signature [FIPS186-2] with SHA-256 hash algorithm [FIPS180-2], Diffie-Hellman [RFC2631] for key agreement, AES [FIPS197] for content encryption}
ALS5：{デジタル署名用DSA [FIPS186-2]とSHA-256ハッシュアルゴリズム[FIPS180-2]、鍵合意用Diffie-Hellman [RFC2631]、コンテンツ暗号化用AES [FIPS197]}
Note: Newer versions of DSA will become available with support for key sizes greater than 1024 bits. New standards for D-H and AES usage are anticipated to require the use of the SHA-256 hash algorithm. The SHA-256 algorithm is now available in draft form.
注：DSAの新しいバージョンでは、1024ビットを超える鍵サイズがサポートされる予定です。D-HとAESの使用に関する新標準では、SHA-256ハッシュアルゴリズムの使用が求められる見込みです。SHA-256アルゴリズムは現在、草案として利用可能です。
Related recommendations on public key sizes:
公開鍵サイズに関する関連推奨事項：
•If an implementation supports AES in conjunction with RSA, the implementation SHOULD also support RSA public key sizes greater than 1024 bits.
•実装がRSAと組み合わせてAESをサポートする場合、1024ビットを超えるRSA公開鍵サイズもサポートすべきです（SHOULD）。
•If an implementation supports AES in conjunction with D-H, the implementation SHOULD also support D-H public key sizes greater than 1024 bits.
•実装がD-Hと組み合わせてAESをサポートする場合、1024ビットを超えるD-H公開鍵サイズもサポートすべきです（SHOULD）。
•If an implementation supports public key sizes greater than 1024 bits when using either DSA or RSA for digital signature, the implementation SHOULD also support SHA-256.
•実装がデジタル署名にDSAまたはRSAを使用し、1024ビットを超える公開鍵サイズをサポートする場合、SHA-256もサポートすべきです（SHOULD）。
Additional algorithm suites will be identified in the future.
今後、追加のアルゴリズムスイートを特定します。
Note: The current Digital Signature Algorithm (DSA) defined in [FIPS186-2] uses a key size of at least 1024 bits. Future versions of FIPS 186 will be defined to allow for key sizes of 1024 bits or longer.
注：[FIPS186-2]で定義された現行のデジタル署名アルゴリズム（DSA）は、少なくとも1024ビットの鍵サイズを使用します。将来のFIPS 186では、1024ビット以上の鍵サイズを許可するよう規定されます。
Support of additional algorithm suites, especially using other FIPS approved algorithms (e.g., the Elliptical Curve Digital Signature Algorithm ECDSA [ANSIX9.62]) or other FIPS approved algorithms [FIPS140-1] or [FIPS140-2], is encouraged to promote interoperability and backward compatibility.
他のFIPS承認済みアルゴリズム、特に楕円曲線デジタル署名アルゴリズムECDSA [ANSIX9.62]などを使用する追加アルゴリズムスイートや、他のFIPS承認済みアルゴリズム[FIPS140-1]または[FIPS140-2]のサポートは、相互運用性と後方互換性を促進するため推奨されます。
However, some older and weaker algorithm suites should be avoided and not trusted. For example, the MD2 message digest algorithm and 512 bit RSA are now considered to be weak by many cryptographers.
ただし、古くて強度の低いアルゴリズムスイートは避け、信頼すべきでありません。例えば、MD2メッセージダイジェストアルゴリズムと512ビットRSAは、多くの暗号研究者から現在、弱いとみなされています。
Further information on cryptographic algorithm suites is provided in Appendix A.
暗号アルゴリズムスイートの詳細については、付録Aを参照してください。
2.1.1.3 Key Wrap Specifications
2.1.1.3 鍵ラップ仕様
In S/MIME V3, management of symmetric cryptographic keys often leads to situations where one symmetric key is used to encrypt (or wrap) another (e.g., sending enveloped data to several recipients). In situations where Triple-DES [FIPS46-3] is used for symmetric key encryption and key wrapping is required, the method for encoding the key wrap is as specified in [RFC3217] (or its successor document) MUST be used. In situations where AES [FIPS197] is used for symmetric key encryption and key wrapping is required, the method for encoding the key wrap as specified in [RFC3394] MUST be used.
S/MIME V3では、共通鍵暗号鍵の管理において、ある共通鍵を別の鍵の暗号化（またはラップ）に使用する状況がよく生じます（例：複数の受信者へのエンベロープデータ送信）。共通鍵暗号と鍵ラップにTriple-DES [FIPS46-3]を使用する場合、[RFC3217]（またはその後継文書）で規定された鍵ラップの符号化方式を使用しなければなりません（MUST）。共通鍵暗号と鍵ラップにAES [FIPS197]を使用する場合、[RFC3394]で規定された鍵ラップの符号化方式を使用しなければなりません（MUST）。
2.1.2 PKI Profile Conformance
2.1.2 PKIプロファイルへの適合
In order to help ensure that S/MIME V3 implementations interoperate securely, it is useful to adopt a profile of the X.509 standard. The most widely accepted PKI profile is the IETF Public Key Infrastructure using X.509 (PKIX) profile developed by the PKIX working group. The PKIX profile [RFC3280] identifies the format and semantics of certificates and CRLs for use on the Internet. Procedures are described for processing and validating certification paths in the Internet environment. The PKIX profile has also been adopted by the Federal PKI Technical Working Group in the “Federal Public Key Infrastructure (PKI) X.509 Certificate and CRL Extensions Profile” [CERTCRL]. Conformance to this S/MIME V3 Profile requires conformance to [CERTCRL].
S/MIME V3実装が安全に相互運用できるようにするには、X.509標準のプロファイルを採用するとよいです。最も広く受け入れられているPKIプロファイルは、PKIX作業部会が策定したIETF Public Key Infrastructure using X.509（PKIX）プロファイルです。PKIXプロファイル[RFC3280]は、インターネットで使用する証明書とCRLの形式および意味を特定します。また、インターネット環境における証明パスの処理と検証の手順を記述します。PKIXプロファイルは、連邦PKI技術作業部会によって「Federal Public Key Infrastructure（PKI）X.509 Certificate and CRL Extensions Profile」[CERTCRL]としても採用されました。本S/MIME V3プロファイルへの適合には、[CERTCRL]への適合が必要です。
2.1.3 Cryptographic Messaging Systems (CMS) Content Types
2.1.3 暗号メッセージングシステム（CMS）のコンテンツ型
Conforming implementations MUST be able to generate and receive the following CMS Content Types embedded in a ContentInfo object as defined in [RFC2630]:
適合実装は、[RFC2630]で定義されたContentInfoオブジェクトに埋め込む次のCMSコンテンツ型を生成・受信できなければなりません（MUST）。
•SignedData
•SignedData
•EnvelopedData
•EnvelopedData
•Receipt
•Receipt
Conforming implementations MUST be able to generate and receive the following CMS content types as embedded content:
適合実装は、埋め込みコンテンツとして次のCMSコンテンツ型を生成・受信できなければなりません（MUST）。
•Data
•Data
Note: The inclusion of Signed Receipts in Sections 2.2, 2.3, and 3.1 implies that implementations MUST include the Receipt content type from [RFC2634].
注：2.2節、2.3節、3.1節に署名付き受領通知が含まれるため、実装は[RFC2634]のReceiptコンテンツ型を含めなければなりません（MUST）。
In S/MIME messages, the Data content type is only used within SignedData or EnvelopedData content types and always contains a MIME-encoded message.
S/MIMEメッセージでは、Dataコンテンツ型はSignedDataまたはEnvelopedDataコンテンツ型内でのみ使用され、常にMIME符号化されたメッセージを含みます。
Conforming implementations MUST be able to process nested S/MIME security layers such that signed data may appear within enveloped data and enveloped data may appear within signed data. Details of nesting of content types within MIME types are contained in [RFC2634] Clauses 1.1 and 1.2. Nesting beyond triple wrapping as defined in [RFC2634] Clauses 1.1 and 1.2 is not required.
適合実装は、署名付きデータをエンベロープデータ内に含めたり、エンベロープデータを署名付きデータ内に含めたりできるよう、入れ子になったS/MIMEセキュリティ層を処理できなければなりません（MUST）。MIME型内のコンテンツ型の入れ子に関する詳細は[RFC2634]の1.1項および1.2項に記載されています。[RFC2634]の1.1項および1.2項で定義される三重ラップを超える入れ子は必須ではありません。
2.1.4 MIME Encoding
2.1.4 MIME符号化
S/MIME is used to secure MIME content. Traditionally S/MIME implementations have used Base64 MIME encoding for all information. (Base64 encoding is used to transfer binary information through Internet (SMTP) mail because Internet mail was originally designed to transfer ASCII information only. Therefore to ensure that binary information is passed through the Internet without modification, it is necessary to translate the information into an ASCII representation such as Base64.) Unfortunately Base64 encoding applied to binary information causes an increase of message size of at least 33 percent and thus represents a waste of network bandwidth, and possibly storage at either end.
S/MIMEはMIMEコンテンツを保護するために使用されます。従来、S/MIME実装はすべての情報にBase64 MIME符号化を使用してきました。（Base64符号化は、インターネットメールが当初ASCII情報のみを転送するよう設計されていたため、インターネット（SMTP）メールを介してバイナリ情報を転送するために使われます。したがって、バイナリ情報を改変せずにインターネット経由で送るには、Base64などのASCII表現に変換する必要があります。）しかし、バイナリ情報にBase64符号化を適用するとメッセージサイズが少なくとも33パーセント増加し、ネットワーク帯域幅、場合によっては送受信側のストレージを浪費します。
S/MIME uses ASN.1 Basic Encoding Rules (BER) to represent data [X.208] [X.209]. There are multiple layers of BER encoded data in S/MIME messages, each usually “wrapped” in Base64 encoding. While it is necessary to have the outermost binary (BER) representation Base64 encoded for passage through the Internet, inner binary representations need not have Base64 encoding applied, although most implementations apply Base64 even to inner binary representations.
S/MIMEは、データ表現にASN.1基本符号化規則（BER）[X.208] [X.209]を使用します。S/MIMEメッセージにはBER符号化データの複数層があり、それぞれ通常Base64符号化で「ラップ」されます。インターネット経由で転送するには最外層のバイナリ（BER）表現をBase64符号化する必要がありますが、内側のバイナリ表現にはBase64符号化を適用する必要はありません。ただし、ほとんどの実装は内側のバイナリ表現にもBase64を適用します。
Conforming implementations MUST be able to receive messages where inner MIME encodings are not individually Base64 encoded. There is no requirement that S/MIME implementations generate messages with inner MIME encodings without Base64, although S/MIME implementations SHOULD be able to generate messages with Base64 encoding applied only to the outermost binary data.
適合実装は、内側のMIME符号化が個別にはBase64符号化されていないメッセージを受信できなければなりません（MUST）。S/MIME実装が内側のMIME符号化にBase64を使わずメッセージを生成する要件はありません。ただし、最外層のバイナリデータのみにBase64符号化を適用したメッセージを生成できるべきです（SHOULD）。
2.1.5 Mail Access Protocols (POP/IMAP)
2.1.5 メールアクセスプロトコル（POP/IMAP）
To send S/MIME messages over the Internet each end user (e.g., e-mail client) must have one or more e-mail accounts on an SMTP-enabled server (i.e., a standard Internet mail server). Normally, each client also needs a “mail access” protocol, (e.g., POP, IMAP) to support transfer of messages to/from the e-mail server and their local computer. With respect to this S/MIME V3 Client Profile, the “mail access” protocol is out-of-scope.
インターネット経由でS/MIMEメッセージを送信するには、各エンドユーザー（例：電子メールクライアント）がSMTP対応サーバー（すなわち標準的なインターネットメールサーバー）上に一つ以上の電子メールアカウントを持つ必要があります。通常、各クライアントはサーバーとローカルコンピューター間でメッセージを転送するため、「メールアクセス」プロトコル（例：POP、IMAP）も必要とします。本S/MIME V3クライアントプロファイルでは、「メールアクセス」プロトコルは適用範囲外です。
2.2 S/MIME Message Generation
2.2 S/MIMEメッセージの生成
S/MIME implementations MUST be able to generate S/MIME messages that are correctly formatted as per IETF S/MIME V3 specifications and include sufficient information for the recipient to verify the signature or decrypt the data. In addition, these messages MAY include information to allow the recipient to generate secure responses.
S/MIME実装は、IETF S/MIME V3仕様に従って正しく形式化され、受信者が署名を検証またはデータを復号するための十分な情報を含むS/MIMEメッセージを生成できなければなりません（MUST）。さらに、受信者が安全な応答を生成できるようにする情報を含めてもよいです（MAY）。
2.2.1 Sending Signed Messages
2.2.1 署名付きメッセージの送信
•S/MIME implementations MUST be able to generate SignerInfo including signed attributes.
•S/MIME実装は、署名付き属性を含むSignerInfoを生成できなければなりません（MUST）。
•S/MIME implementations MUST be able to generate SMIMECapabilities and signingTime attributes.
•S/MIME実装は、SMIMECapabilities属性およびsigningTime属性を生成できなければなりません（MUST）。
•S/MIME implementations SHOULD be able to generate signingCertificate attributes.
•S/MIME実装は、signingCertificate属性を生成できるべきです（SHOULD）。
•S/MIME implementations MUST be able to include user certificates and appropriate CRLs.
•S/MIME実装は、ユーザー証明書および適切なCRLを含められなければなりません（MUST）。
•S/MIME implementations MUST be able to generate multipart/signed (i.e., "clear") messages.
•S/MIME実装は、multipart/signed（すなわち「clear」）メッセージを生成できなければなりません（MUST）。
•S/MIME implementations MUST be able to request return signed receipt messages (as specified in [RFC 2634]) where the receipt goes to the message originator. (Requesting a return signed receipt where the receipt is directed to a third party is out of scope for this profile, and thus claims to conformance will not be tested. However, correctly responding to the reception of such a signed receipt request is required, as stated in Clause 2.3.2)
•S/MIME実装は、受領通知の送付先がメッセージ送信元となる署名付き受領通知メッセージ（[RFC 2634]で規定）を要求できなければなりません（MUST）。受領通知を第三者宛てにする要求は本プロファイルの適用範囲外であり、その適合性は試験しません。ただし、第2.3.2項に記載のとおり、そのような署名付き受領通知要求を受信した際に正しく応答することは必須です。
2.2.2 Sending Encrypted Messages
2.2.2 暗号化メッセージの送信
•S/MIME implementations MUST be able to generate symmetric keys, encrypt messages using these keys, and encrypt symmetric keys using PKCS#1 v1.5 RSA keys as defined in [RFC2313].
•S/MIME実装は、共通鍵を生成し、その鍵でメッセージを暗号化し、PKCS#1 v1.5 RSA鍵（[RFC2313]で定義）を用いて共通鍵を暗号化できなければなりません（MUST）。
•S/MIME implementations SHOULD be able to generate Diffie-Hellman keys and derive pairwise symmetric key-encryption keys (KEK) as defined in [RFC2631], and then use the KEK to encrypt the content-encryption key as specified in [RFC2630].
•S/MIME実装は、Diffie-Hellman鍵を生成して[RFC2631]で定義されたペア単位の共通鍵暗号化鍵（KEK）を導出し、その後、[RFC2630]で規定されたとおりにKEKを用いてコンテンツ暗号化鍵を暗号化できるべきです（SHOULD）。
•S/MIME implementations MUST be able to encrypt a message for multiple recipients.
•S/MIME実装は、複数の受信者向けにメッセージを暗号化できなければなりません（MUST）。
•When the sender supports more than one method for key management, the implementation SHOULD automatically select an appropriate method based on the contents of each recipient’s key management certificates (usually obtained from previously received messages).
•送信者が複数の鍵管理方式をサポートする場合、実装は、各受信者の鍵管理証明書（通常は以前に受信したメッセージから取得される）の内容に基づき、適切な方式を自動的に選択すべきです（SHOULD）。
•When the sender supports more than one method for symmetric encryption, the implementation SHOULD automatically select the appropriate encryption method based on each recipient’s SMIMECapabilities attributes from previously received messages.
•送信者が複数の共通鍵暗号方式をサポートする場合、実装は、以前に受信したメッセージに含まれる各受信者のSMIMECapabilities属性に基づき、適切な暗号方式を自動的に選択すべきです（SHOULD）。
•S/MIME implementations MUST be able to construct a certification path for the receiver’s key management certificate, including CRLs, using the Lightweight Directory Access Protocol (LDAP). This includes:
•S/MIME実装は、Lightweight Directory Access Protocol（LDAP）を用い、CRLを含む受信者の鍵管理証明書の証明パスを構築できなければなりません（MUST）。これには次が含まれます。
•the ability to build the path.
•証明パスを構築する機能。
•the ability to fetch the recipient’s certificate using LDAP.
•LDAPを用いて受信者の証明書を取得する機能。
•the ability to fetch CRLs using LDAP.
•LDAPを用いてCRLを取得する機能。
•the ability to fetch issuer certificates using LDAP.
•LDAPを用いて発行者証明書を取得する機能。
•S/MIME implementations MUST validate the certification path where the end certificate is the receiver’s key management certificate or reject the certificate.
•S/MIME実装は、終端証明書が受信者の鍵管理証明書となる証明パスを検証するか、その証明書を拒否しなければなりません（MUST）。
2.2.3 Sending Signed and Encrypted Messages
2.2.3 署名付きかつ暗号化されたメッセージの送信
•S/MIME implementations MUST be able to satisfy the requirements for sending signed messages as in Clause 2.2.1 above and MUST be able to satisfy the requirements for sending encrypted messages as in Clause 2.2.2 above.
•S/MIME実装は、上記2.2.1項の署名付きメッセージ送信要件を満たせなければなりません（MUST）。また、上記2.2.2項の暗号化メッセージ送信要件も満たせなければなりません（MUST）。
•S/MIME implementations MUST be able to generate signed and then encrypted messages. This includes generating a symmetric key and encrypting the message.
•S/MIME実装は、署名してから暗号化するメッセージを生成できなければなりません（MUST）。これには、共通鍵を生成し、その鍵でメッセージを暗号化することが含まれます。
•S/MIME implementations SHOULD be able to use the application/pkcs7-mime type to generate signed then encrypted messages.
•S/MIME実装は、application/pkcs7-mime型を使用して、署名してから暗号化するメッセージを生成できるべきです（SHOULD）。
2.2.4 Building MIME Header
2.2.4 MIMEヘッダーの構築
•S/MIME implementations MUST be able to create properly formatted MIME headers as per [RFC2633] for each of the message types above.
•S/MIME実装は、上記の各メッセージ種別について、[RFC2633]に従って適切な形式のMIMEヘッダーを作成できなければなりません（MUST）。
•S/MIME implementations MUST be able to create the intermediate MIME wrappers.
•S/MIME実装は、中間MIMEラッパーを作成できなければなりません（MUST）。
2.3 S/MIME Message Reception and Processing
2.3 S/MIMEメッセージの受信と処理
S/MIME implementations MUST be able to receive and process S/MIME messages that are correctly formatted. Recipients MUST be able to verify the signature or decrypt the data using the information provided by the sender. Where necessary, the recipient MUST be able to augment sender-provided information with certificates, CRLs, or other status information. (For example, the recipient may use LDAP for retrievals of CRLs.)
S/MIME実装は、正しい形式のS/MIMEメッセージを受信して処理できなければなりません（MUST）。受信者は、送信者が提供した情報を用いて署名を検証するか、データを復号できなければなりません（MUST）。必要に応じて、受信者は証明書、CRL、またはその他の状態情報を用いて、送信者提供の情報を補完できなければなりません（MUST）。たとえば、受信者はCRLを取得するためにLDAPを使用してもよいです。
2.3.1 Parsing MIME Header
2.3.1 MIMEヘッダーの解析
•S/MIME implementations MUST be able to process properly formatted MIME headers.
•S/MIME実装は、適切な形式のMIMEヘッダーを処理できなければなりません（MUST）。
2.3.2 Receiving Signed Messages
2.3.2 署名済みメッセージの受信
•S/MIME implementations MUST be able to process SignerInfo including signed attributes.
•S/MIME実装は、署名属性を含むSignerInfoを処理できなければなりません（MUST）。
•S/MIME implementations MUST be able to process both multipart/signed (i.e., "clear") and application/pkcs7-signature MIME Type (i.e., "opaque") signed messages.
•S/MIME実装は、multipart/signed（すなわち"clear"）とapplication/pkcs7-signature MIMEタイプ（すなわち"opaque"）の両方の署名済みメッセージを処理できなければなりません（MUST）。
•S/MIME implementations MUST be able to acquire certificates by extracting certificates from incoming signed messages.
•S/MIME実装は、受信した署名済みメッセージから証明書を抽出して取得できなければなりません（MUST）。
•S/MIME implementations MUST handle unknown attributes gracefully by accepting the message and informing the user.
•S/MIME実装は、未知の属性を適切に扱い、メッセージを受け入れたうえでユーザーに通知しなければなりません（MUST）。
•S/MIME implementations MUST be able to construct a certification path for the sender’s signature certificate, including CRLs, using LDAP. This is further described in Clause 2.4.4. below.
•S/MIME実装は、LDAPを使用し、CRLを含めて送信者の署名証明書の証明パスを構築できなければなりません（MUST）。これは、以下の2.4.4項で詳述します。
•S/MIME implementations MUST validate the certification path where the end certificate is the sender’s signature certificate or reject the certificate.
•S/MIME実装は、終端証明書が送信者の署名証明書である証明パスを検証するか、その証明書を拒否しなければなりません（MUST）。
•Whenever an S/MIME implementation indicates the signature on a message is valid, that implementation MUST display an authenticated name (e.g., the subject name or a subjectAltName) from the signer’s certificate.
•S/MIME実装がメッセージの署名を有効と示す場合は常に、その実装は署名者の証明書に含まれる認証済みの名前（例：subject nameまたはsubjectAltName）を表示しなければなりません（MUST）。
•S/MIME implementations MUST compare the SubjectAltName.rfc822Name or PKCS#9 emailAddress in the signer's certificate with the actual e-mail address used in the received message's “From” or “Sender” field (See [RFC3280] and [RFC2632].).
•S/MIME実装は、署名者の証明書にあるSubjectAltName.rfc822NameまたはPKCS#9 emailAddressを、受信メッセージの「From」または「Sender」フィールドで使用された実際の電子メールアドレスと比較しなければなりません（MUST）（[RFC3280]および[RFC2632]参照）。
1.If the addresses do not match or the certificate does not contain any e-mail addresses, the S/MIME implementation MUST display information to the user to allow the user to accept or reject the message. This information MUST be displayed the first time that an e-mail message arrives with a unique pair of “From” address and signer certificate.
1.アドレスが一致しない場合、または証明書に電子メールアドレスが含まれない場合、S/MIME実装は、ユーザーがメッセージを受け入れるか拒否するかを判断できるよう、情報を表示しなければなりません（MUST）。この情報は、「From」アドレスと署名者証明書の一意な組み合わせを持つ電子メールメッセージが初めて到着したときに表示しなければなりません（MUST）。
2.To avoid continual display of information in environments where certificates either do not contain e-mail address, or there are frequent mismatches between e-mail addresses used in the “From” field of RFC822 messages and those in the signer’s certificate, the implementation SHOULD allow the user the option of suppressing further display of information on subsequent messages received with the same unique pair of “From” address and signer certificate.
2.証明書に電子メールアドレスが含まれない環境、またはRFC822メッセージの「From」フィールドで使用される電子メールアドレスと署名者証明書内のアドレスとの不一致が頻発する環境で、情報が繰り返し表示されることを避けるため、実装は、同じ「From」アドレスと署名者証明書の一意な組み合わせを持つ後続メッセージについて、以後の情報表示を抑制する選択肢をユーザーに提供すべきです（SHOULD）。
3.The implementation MUST clearly differentiate between authenticated names (from the signer’s certificate) and unauthenticated names (e.g., the rfc822 “phrase” in “mailbox” in the address specification in the “From” field) when displaying signature validation information.
3.署名検証情報を表示する際、実装は、署名者の証明書に由来する認証済みの名前と、未認証の名前（例：「From」フィールドのアドレス指定における「mailbox」内のrfc822「phrase」）を明確に区別しなければなりません（MUST）。
•S/MIME implementations MUST be able to generate return signed receipt messages as specified in [RFC2634]. Signed receipts SHOULD be sent to the entities named in the receiptsTo field of the receipt request according to the processing described in Section 2 of [RFC2634]. Note: As specified in [RFC2634], this processing may cause modification in determining if return signed receipts should be sent according to the value of the mlExpansionHistory attribute (if any) contained in received messages.
•S/MIME実装は、[RFC2634]に規定された署名付き受領通知メッセージを生成できなければなりません（MUST）。署名付き受領通知は、[RFC2634]第2節に記載された処理に従い、受領通知要求のreceiptsToフィールドに指定されたエンティティに送信すべきです（SHOULD）。注：[RFC2634]に規定されているように、この処理では、受信メッセージに含まれるmlExpansionHistory属性（存在する場合）の値に従って署名付き受領通知を返送すべきかどうかを判定する際に、変更が生じることがあります。
2.3.3 Receiving Encrypted Messages
2.3.3 暗号化メッセージの受信
•S/MIME implementations MUST be able to process encrypted messages. This includes recovering the symmetric key and using the key to decrypt the message.
•S/MIME実装は、暗号化メッセージを処理できなければなりません（MUST）。これには、共通鍵を復元し、その鍵を用いてメッセージを復号することが含まれます。
•S/MIME implementations MUST be able to process messages for one or more recipients.
•S/MIME実装は、1人以上の受信者宛てのメッセージを処理できなければなりません（MUST）。
•Receiving agents SHOULD allow a transparent selection of the appropriate private key for decryption of an incoming message when the recipient has multiple certificates (each associated with a private key) used for key management.
•受信エージェントは、受信者が鍵管理に使用する複数の証明書（それぞれが秘密鍵に対応する）を持つ場合、受信メッセージの復号に適した秘密鍵を利用者に意識させずに選択できるようにすべきです（SHOULD）。
2.3.4 Receiving Signed and Encrypted Messages
2.3.4 署名および暗号化されたメッセージの受信
•S/MIME implementations MUST be able to receive and process messages that are signed and then encrypted. Implementations SHOULD be able to receive and process messages that are signed, encrypted, and then signed again. (Triple wrapping as defined in [RFC2634].) Implementations that can process arbitrary layers of wrapping are preferable.
•S/MIME実装は、署名してから暗号化されたメッセージを受信して処理できなければなりません（MUST）。実装は、署名、暗号化、さらに再度署名されたメッセージを受信して処理できるべきです（SHOULD）（[RFC2634]で定義される三重ラッピング）。任意の階層数のラッピングを処理できる実装が望まれます。
2.3.5 Processing Return Receipts
2.3.5 返送受領通知の処理
•S/MIME implementations MUST be able to process return signed receipts as specified in [RFC2634] for messages that the implementation generated and are still retained on the client system. Receipts for messages generated by a third party are out of scope for this profile, and thus claims to conformance will not be tested.
•S/MIME実装は、実装自身が生成し、クライアントシステム上に保持されているメッセージについて、[RFC2634]に規定された返送署名付き受領通知を処理できなければなりません（MUST）。第三者が生成したメッセージの受領通知は本プロファイルの対象外であるため、適合性の主張は試験されません。
•S/MIME implementations MUST be able to match receipts to messages automatically.
•S/MIME実装は、受領通知をメッセージに自動的に対応付けられなければなりません（MUST）。
•When S/MIME implementations process return signed receipt messages, the requirements for receiving signed messages as in Clause 2.3.2 above MUST be satisfied.
•S/MIME実装が返送署名付き受領通知メッセージを処理する際は、上記2.3.2節の署名済みメッセージ受信要件を満たさなければなりません（MUST）。
2.4 Certificate Processing
2.4 証明書の処理
S/MIME is a PKI-enabled secure application. Specifically, S/MIME V3 implementations MUST obtain and validate X.509 public key certificates to validate the signature on a message or exchange symmetric key material. If critical PKI features are not present or are weak, the security of S/MIME implementations will be adversely affected. PKI features are described in detail in [RFC3280], "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile."
S/MIMEはPKIに対応したセキュアアプリケーションです。具体的には、S/MIME V3実装は、メッセージの署名を検証するか共通鍵の情報を交換するため、X.509公開鍵証明書を取得して検証しなければなりません（MUST）。重要なPKI機能が欠けているか脆弱である場合、S/MIME実装のセキュリティは悪影響を受けます。PKI機能の詳細は、[RFC3280]に規定される"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"に記載されています。
The PKI features may be divided into four basic categories. These categories are explained in detail below.
PKI機能は、基本的に4つのカテゴリに分けられます。これらのカテゴリについて、以下で詳しく説明します。
2.4.1 X.509 Certificate Processing
2.4.1 X.509証明書の処理
S/MIME implementations MUST be able to process all critical or optionally critical certificate extensions in the Federal Certificate and CRL Profile [CERTCRL]. S/MIME implementations MUST not reject certificates with unrecognized non-critical extensions. S/MIME agents MUST have the capability to support distinct certificates for digital signature and key management security services for both message origination and reception.
S/MIME実装は、Federal Certificate and CRL Profile [CERTCRL]におけるすべてのクリティカルまたは任意にクリティカルとされる証明書拡張を処理できなければなりません（MUST）。S/MIME実装は、認識されない非クリティカル拡張を含む証明書を拒否してはなりません（MUST）。S/MIMEエージェントは、メッセージの送信と受信の両方について、電子署名用と鍵管理用のセキュリティサービスに別個の証明書を使用できなければなりません（MUST）。
2.4.2 X.509 CRL Processing
2.4.2 X.509 CRLの処理
S/MIME implementations MUST be able to process all critical or optionally critical CRL extensions in the Federal Certificate and CRL Profile [CERTCRL]. S/MIME implementations MUST not reject CRLs with unrecognized non-critical extensions.
S/MIME実装は、Federal Certificate and CRL Profile [CERTCRL]におけるすべてのクリティカルまたは任意にクリティカルとされるCRL拡張を処理できなければなりません（MUST）。S/MIME実装は、認識されない非クリティカル拡張を含むCRLを拒否してはなりません（MUST）。
2.4.3 Path Validation
2.4.3 パス検証
S/MIME implementations MUST be able to validate a certification path according to [RFC3280], Section 6. S/MIME implementations MUST be able to use X.509 CRLs to establish certificate status for path validation. At a minimum, the following aspects of path validation MUST be implemented:
S/MIME実装は、[RFC3280]第6節に従って証明書パスを検証できなければなりません（MUST）。S/MIME実装は、パス検証のためにX.509 CRLを使用して証明書の状態を確立できなければなりません（MUST）。少なくとも、パス検証の次の側面を実装しなければならない（MUST）：
•certificate policies, policy constraints, and policy mapping
•証明書ポリシー、ポリシー制約、およびポリシーマッピング
•basic constraints
•基本制約
•name constraints for distinguished names and RFC822 names
•識別名およびRFC822名に対する名前制約
•DSA parameter inheritance
•DSAパラメーターの継承
•processing certification paths with multiple signature algorithms
•複数の署名アルゴリズムを使用する証明書パスの処理
•name chaining
•名前チェーン
•signature verification
•署名検証
•validity date checking
•有効期間の日付確認
•revocation checking by processing CRLs
•CRLの処理による失効確認
•key usage/extended key usage
•key usage／extended key usage
•CRL distribution points
•CRL配布点
•CRL entry extensions: invalidity date, reason code.
•CRLエントリー拡張：無効化日、理由コード。
2.4.4 Path Building
2.4.4 パス構築
Although not described in [RFC3280], path building is an important aspect of PKI-enabled applications. S/MIME implementations MUST be able to construct certification paths between an accepted trust point and a sender's or a recipient's certificate(s). Path building algorithms are not specified in any standard or specification. However, a variety of resources are available to assist in path building using heuristic methods. These resources include standard directory attributes and a variety of supplementary information in certificate extensions. S/MIME implementations MUST be able to take advantage of this information to provide complete path building services. At a minimum, the following features MUST be supported:
[RFC3280]には記載されていませんが、パス構築はPKI対応アプリケーションの重要な要素です。S/MIME実装は、受け入れ済みの信頼点と送信者または受信者の証明書との間に証明書パスを構築できなければなりません（MUST）。パス構築アルゴリズムは、いかなる標準または仕様にも規定されていません。しかし、ヒューリスティックな手法でパス構築を支援するためのさまざまなリソースが利用できます。これらのリソースには、標準ディレクトリ属性や、証明書拡張に含まれる各種の補足情報があります。S/MIME実装は、完全なパス構築サービスを提供するため、この情報を活用できなければなりません（MUST）。少なくとも、次の機能をサポートしなければならない（MUST）：
•retrieve CRLs using LDAP from the following directory attributes:
•次のディレクトリ属性を使用して、LDAP経由でCRLを取得すること：
•certificate revocation list, and
•certificate revocation list（証明書失効リスト）、および
•authority revocation list.
•authority revocation list（認証局失効リスト）。
•retrieve certificates using LDAP from the following directory attributes:
•次のディレクトリ属性を使用して、LDAP経由で証明書を取得すること：
•Cross certificate pair,
•Cross certificate pair（クロス証明書ペア）、
•CA certificate, and
•CA certificate（CA証明書）、および
•user certificate.
•user certificate（ユーザー証明書）。
•locate certificates in directory entries through at least one of the following methods:
•少なくとも次のいずれかの方法を通じて、ディレクトリエントリー内の証明書を特定すること：
•Authority Information Access (AIA) extension,
•Authority Information Access（AIA）拡張、
•Subject Information Access (SIA) extension, or
•Subject Information Access（SIA）拡張、または
•retrieval from a well-known directory.
•周知のディレクトリからの取得。
•locate CRLs in directory entries through both of the following methods:
•次の両方の方法を通じて、ディレクトリエントリー内のCRLを特定すること：
•CRL distribution point extension, and
•CRL配布点拡張、および
•retrieval from a well-known directory.
•周知のディレクトリからの取得。
The use of the above features is intended to allow implementations to build certification paths in non-hierarchical PKIs (e.g., across bridge PKIs.)
上記の機能を使用することで、実装が非階層型PKI（例：ブリッジPKI間）において証明書パスを構築できるようにすることを意図しています。
3 Support for Enhanced Security Services for S/MIME (RFC 2634)
3 S/MIMEの拡張セキュリティサービスのサポート（RFC 2634）
The IETF has defined a set of Enhanced Security Services (ESS) for S/MIME in [RFC2634]. The services defined include signed receipts, security labels, secure mailing lists, and an extended method of identifying the signer’s certificate(s). This profile does not require conformance to [RFC2634] with the exception that signed receipt requesting, processing, and generation is required as specified in Clause 3.1 of this profile. However, mail agents that include support for any of these ESS services may optionally claim support for any or all of these services, either in origination of messages, receipt of messages, or both. Note that some optional services defined in [RFC2634] are out of scope for this profile as specified below, and thus claims to conformance will not be tested.
IETFは、[RFC2634]でS/MIME向けの拡張セキュリティサービス（ESS）を定義しています。定義されたサービスには、署名付き受領通知、セキュリティラベル、セキュアメーリングリスト、および署名者の証明書を識別する拡張方式が含まれます。本プロファイルでは、[RFC2634]への適合を要求しません。ただし、署名付き受領通知の要求、処理、および生成については、本プロファイルの3.1節に規定された要件を満たさなければなりません。ただし、いずれかのESSサービスをサポートするメールエージェントは、メッセージの送信時、受信時、またはその両方において、これらのサービスの一部またはすべてをサポートすると任意に主張してもよいです。[RFC2634]で定義される任意サービスの一部は、以下に示すとおり本プロファイルの対象外であり、適合性の主張は試験されないことに注意すること。
3.1 Signed Receipts
3.1 署名付き受領通知
Support for signed receipts is one of the four optional security services defined in [RFC2634]. For the purposes of this Profile, e-mail agents MUST be able to request, generate, and process signed receipts as described in [RFC2634].
署名付き受領通知のサポートは、[RFC2634]で定義される4つの任意セキュリティサービスの1つです。本プロファイルでは、電子メールエージェントは、[RFC2634]に記載の署名付き受領通知を要求、生成、および処理できなければなりません（MUST）。
•S/MIME agents that originate messages MUST be able to generate signed receipt requests for signed messages as defined in [RFC2634]. (See Clause 2.2.1 above.)
•メッセージを送信するS/MIMEエージェントは、[RFC2634]で定義される署名済みメッセージ用の署名付き受領通知要求を生成できなければなりません（MUST）（上記2.2.1節参照）。
•S/MIME agents that receive messages MUST be able to generate signed receipts for signed messages that they receive containing signed receipt requests as defined in [RFC2634]. (See Clause 2.3.2 above.)
•メッセージを受信するS/MIMEエージェントは、[RFC2634]で定義される署名付き受領通知要求を含む署名済みメッセージを受信した場合、そのメッセージに対する署名付き受領通知を生成できなければなりません（MUST）（上記2.3.2節参照）。
•S/MIME agents that receive messages MUST be able to process signed receipts (including signature verification) as defined in [RFC2634]. (See Clause 2.3.5 above.)
•メッセージを受信するS/MIMEエージェントは、[RFC2634]で定義される署名付き受領通知（署名検証を含む）を処理できなければなりません（MUST）（上記2.3.5節参照）。
•Mail list agent processing is beyond the scope of this profile. However, S/MIME agents MUST be able to process mlExpansionHistory attributes as defined in Section 2 of [RFC2634].
•メーリングリストエージェントの処理は本プロファイルの対象外です。ただし、S/MIMEエージェントは、[RFC2634]第2節で定義されるmlExpansionHistory属性を処理できなければなりません（MUST）。
3.2 Security Labels
3.2 セキュリティラベル
Support for security labels is one of the four optional security services defined in [RFC2634]. If an S/MIME implementation claims to conform to the security label service defined in Clause 3 of [RFC2634], then the following requirements are imposed on the implementation:
セキュリティラベルのサポートは、[RFC2634]で定義される4つの任意セキュリティサービスの1つです。S/MIME実装が[RFC2634]第3節で定義されるセキュリティラベルサービスに適合すると主張する場合、実装には次の要件が課される：
•S/MIME agents that originate messages MUST be able to generate security labels as defined in [RFC2634].
•メッセージを送信するS/MIMEエージェントは、[RFC2634]で定義されるセキュリティラベルを生成できなければなりません（MUST）。
•S/MIME agents MUST be able to display security labels in received messages as defined in [RFC2634]. S/MIME agents MUST be able to examine the security label on a received message and determine whether the recipient is allowed to see the contents of the message. If the recipient is not allowed to see the message contents then the agent MUST not display the message contents.
•S/MIMEエージェントは、[RFC2634]で定義されるとおり、受信メッセージのセキュリティラベルを表示できなければなりません（MUST）。S/MIMEエージェントは、受信メッセージのセキュリティラベルを調べ、受信者にメッセージの内容を閲覧する権限があるかどうかを判定できなければなりません（MUST）。受信者にメッセージ内容の閲覧が許可されていない場合、エージェントはその内容を表示してはなりません（MUST）。
•The generation and processing of Equivalent Security Labels is beyond the scope of this profile, but may be added to a future profile. However, as stated in [RFC2634], “[a]ll receiving agents SHOULD recognize equivalentLabels attributes even if they do not process them.”
•等価セキュリティラベルの生成と処理は本プロファイルの対象外ですが、将来のプロファイルに追加されることがあります。[RFC2634]に記載のとおり、「すべての受信エージェントは、処理しない場合でもequivalentLabels属性を認識すべきです（SHOULD）。」
3.3 Secure Mailing Lists
3.3 セキュアメーリングリスト
Support for Secure Mailing Lists (“Mail List Management”) is one of the four optional security services defined in [RFC2634]. Mail list agent processing is beyond the scope of this profile but may be added to a future profile. However, S/MIME implementations MUST be able to process received signed messages that contain the mlExpansionHistory attribute as described in Clause 3.1 above.
セキュアメーリングリスト（「メーリングリスト管理」）のサポートは、[RFC2634]で定義される4つの任意セキュリティサービスの1つです。メーリングリストエージェントの処理は本プロファイルの対象外ですが、将来のプロファイルに追加されることがあります。ただし、S/MIME実装は、上記3.1節に記載のとおり、mlExpansionHistory属性を含む受信署名済みメッセージを処理できなければなりません（MUST）。
3.4 Signing Certificate Attribute
3.4 署名証明書属性
Support for Signing Certificate Attributes is one of the four optional security services defined in [RFC2634]. If an S/MIME implementation claims to conform to the Signing Certificate Attribute requirements defined in Clause 5 of [RFC2634], then the following requirements are imposed on the implementation:
署名証明書属性のサポートは、[RFC2634]で定義される4つの任意セキュリティサービスの1つです。S/MIME実装が[RFC2634]第5節で定義される署名証明書属性の要件に適合すると主張する場合、実装には次の要件が課される：
•S/MIME agents that originate messages MUST be able to generate messages that contain a signing certificate attribute as defined in [RFC2634].
•メッセージを送信するS/MIMEエージェントは、[RFC2634]で定義される署名証明書属性を含むメッセージを生成できなければなりません（MUST）。
•S/MIME agents that receive messages MUST be able to properly process messages that contain a signing certificate attribute as defined in [RFC2634].
•メッセージを受信するS/MIMEエージェントは、[RFC2634]で定義される署名証明書属性を含むメッセージを適切に処理できなければなりません（MUST）。
4 Optional Features and Notes on Testing
4 任意機能および試験に関する注記
Since the functionality offered by these optional features may be achieved through other means, inclusion of these options in S/MIME implementations is recommended, but not required.
これらの任意機能が提供する機能は他の方法でも実現できる場合があるため、S/MIME実装にこれらのオプションを含めることは推奨されますが、必須ではありません。
4.1 Generate Application/pkcs7-signature MIME Type (Opaque) Signed Messages
4.1 application/pkcs7-signature MIMEタイプ（opaque）署名済みメッセージの生成
Sending agents SHOULD have the capability to generate application/pkcs7-signature MIME Type (i.e., “opaque”) signed messages.
送信エージェントは、application/pkcs7-signature MIMEタイプ（すなわち「opaque」）の署名済みメッセージを生成する機能を備えるべきです（SHOULD）。
4.2 Self-Signed Certificates
4.2 自己署名証明書
Sending and receiving agents SHOULD have the capability to support self-signed certificates by accepting them as trust anchors.
送信エージェントおよび受信エージェントは、自己署名証明書を信頼アンカーとして受け入れることで、それらをサポートする機能を備えるべきです（SHOULD）。
4.3 Sending CRLs
4.3 CRLの送信
Sending agents SHOULD have the capability to include appropriate CRLs with outgoing messages (i.e., CRLs which are associated with the sender's certificates).
送信エージェントは、送信メッセージに適切なCRL（すなわち、送信者の証明書に関連付けられたCRL）を含める機能を備えるべきです（SHOULD）。
4.4 Selective Trust of Certificates
4.4 証明書の選択的信頼
S/MIME agents SHOULD provide the capability to configure the set of trust anchors, (i.e., set the root trust certificates).
S/MIMEエージェントは、信頼アンカーの集合（すなわち、ルート信頼証明書の集合）を設定する機能を提供すべきです（SHOULD）。
4.5 Acquiring Certificates
4.5 証明書の取得
S/MIME agents SHOULD have the capability to acquire certificates in either of the following ways: 1) Loading certificates (or chains of certificates) from *.p7c and *.p7m files (file extension types) and messages as defined in [RFC2633].
S/MIMEエージェントは、次のいずれかの方法で証明書を取得する機能を備えるべきです（SHOULD）。1) [RFC2633]で定義される*.p7cおよび*.p7mファイル（ファイル拡張子の種類）とメッセージから証明書（または証明書チェーン）を読み込みます。
2) Loading certificates from commonly used (e.g., *.cer and *.crt (binary encoded certificates)) file extension types.
2) 一般的に使用される拡張子（例：*.cerおよび*.crt（バイナリ形式の証明書））のファイルから証明書を読み込みます。
Note: Lookup of certificates (and chains of certificates) from a LDAP repository is required as stated in Clause 2.2.2.
注：LDAPリポジトリから証明書（および証明書チェーン）を検索することは、2.2.2項に記載のとおり必須です。
4.6 Importing/Exporting PKCS #12 Credentials
4.6 PKCS #12認証情報のインポート／エクスポート
S/MIME agents SHOULD have the capability to import PKCS #12 objects as defined in [PKCS#12].
S/MIMEエージェントは、[PKCS#12]で定義されるPKCS #12オブジェクトをインポートする機能を備えるべきです（SHOULD）。
4.7 Notes on Testing and Scope
4.7 試験と適用範囲に関する注記
•Some testing requires “human scoring” because a user interface is involved. For example, as stated in Clause 2.3.2: “S/MIME implementations MUST ensure that either the SubjectAltName.rfc822Name or PKCS#9 emailAddress in the signer's certificate matches the actual e-mail address used in the received message's “From” or “Sender” field (See [RFC3280] and [RFC2632].) If the addresses do not match, the S/MIME implementation MUST display information to the user to allow the user to accept or reject the message.
•ユーザーインターフェースが関わるため、一部の試験では「人手による評価」が必要となります。たとえば2.3.2項に記載のとおり、「S/MIME実装は、署名者の証明書にあるSubjectAltName.rfc822NameまたはPKCS#9 emailAddressが、受信したメッセージの“From”または“Sender”フィールドで使用された実際の電子メールアドレスと一致することを保証しなければなりません（MUST）（[RFC3280]および[RFC2632]を参照してください）。アドレスが一致しない場合、S/MIME実装は、ユーザーがそのメッセージを承認または拒否できるように情報を表示しなければなりません（MUST）。」
There is no efficient method to automate verification that the S/MIME implementation actually displays the mismatch information. Thus, human scoring is required to evaluate the implementation’s conformance to this requirement.
S/MIME実装が不一致情報を実際に表示することを自動で検証する効率的な方法はありません。そのため、実装がこの要件に適合しているかを評価するには人手による評価が必要です。
•Security of operating system and e-mail mechanisms are beyond the scope of this profile. For example, system operators must ensure that the operating system itself is secured, and that the e-mail system is secure. This profile addresses only the security aspects of IETF-developed S/MIME extensions.
•オペレーティングシステムおよび電子メール機構のセキュリティは、本プロファイルの適用範囲外です。たとえば、システム運用者はオペレーティングシステム自体と電子メールシステムが安全であることを確保しなければなりません。本プロファイルは、IETFが策定したS/MIME拡張のセキュリティ面のみを扱います。
5 References
5 参考文献
•[Adams00] Understanding Public-Key Infrastructure, Carlisle Adams and Steve Lloyd, Macmillan Technical Publishing, Indianapolis, Indiana, 2000
•[Adams00]「公開鍵基盤を理解する」、Carlisle AdamsおよびSteve Lloyd著、Macmillan Technical Publishing、インディアナ州インディアナポリス、2000年。
•[ANSIX9.31] ANSI X9.31-1997, X9.31 Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA), 1997
•[ANSIX9.31] ANSI X9.31-1997「金融サービス業界向け可逆公開鍵暗号を用いたデジタル署名（rDSA）」、1997年。
•[ANSIX9.44] ANSI X9.44-2001, Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Factoring-Based Cryptography. Working Draft, January 12, 2001
•[ANSIX9.44] ANSI X9.44-2001「金融サービス業界向け公開鍵暗号：素因数分解に基づく暗号による鍵共有および鍵転送」。作業草案、2001年1月12日。
•[ANSIX9.57] ANSI X9.57-1997, Public Key Cryptography for the Financial Services Industry: Certificate Management, 1997
•[ANSIX9.57] ANSI X9.57-1997「金融サービス業界向け公開鍵暗号：証明書管理」、1997年。
•[ANSIX9.62] ANSI X9.62-1999, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), 1998
•[ANSIX9.62] ANSI X9.62-1999「金融サービス業界向け公開鍵暗号：楕円曲線デジタル署名アルゴリズム（ECDSA）」、1998年。
•[ANSIX9.63] ANSIX9.63-2001, Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography. Working Draft, May 8, 2001
•[ANSIX9.63] ANSI X9.63-2001「金融サービス業界向け公開鍵暗号：楕円曲線暗号による鍵共有および鍵転送」。作業草案、2001年5月8日。
•[CERTCRL], Federal Public Key Infrastructure (PKI) X.509 Certificate and CRL Extensions Profile, http://csrc.nist.gov/pki/twg/y2002/papers/twg-02-04.xls (Note: In Excel Format), 15 February 2002
•[CERTCRL]「連邦公開鍵基盤（PKI）X.509証明書およびCRL拡張プロファイル」。http://csrc.nist.gov/pki/twg/y2002/papers/twg-02-04.xls（注：Excel形式）、2002年2月15日。
•[FIPS46-3], FIPS 46-3, Data Encryption Standard (DES), Defines and specifies the use of DES and Triple DES, http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf, November 1999
•[FIPS46-3] FIPS 46-3「データ暗号化規格（DES）」：DESおよびTriple DESの使用を定義し、規定します。http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf、1999年11月。
•[FIPS140-1], FIPS 140-1, Security Requirements For Cryptographic Modules, http://csrc.nist.gov/publications/fips/fips140-1/fips1401.pdf
•[FIPS140-1] FIPS 140-1「暗号モジュールのセキュリティ要件」。http://csrc.nist.gov/publications/fips/fips140-1/fips1401.pdf
•[FIPS140-2], FIPS 140-2, Security Requirements For Cryptographic Modules, http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
•[FIPS140-2] FIPS 140-2「暗号モジュールのセキュリティ要件」。http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
•[FIPS180-1], Secure Hash Standard, http://www.itl.nist.gov/fipspubs/fip180-1.htm
•[FIPS180-1]「セキュアハッシュ標準」。http://www.itl.nist.gov/fipspubs/fip180-1.htm
•[FIPS180-2], Secure Hash Standard, http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf
•[FIPS180-2]「セキュアハッシュ標準」。http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf
•[FIPS186-2], FIPS 186-2, Digital Signature Standard, http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf, Feb. 2000
•[FIPS186-2] FIPS 186-2「デジタル署名標準」。http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf、2000年2月。
•[FIPS197], Specification for the Advanced Encryption Standard (AES), http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf, November 26, 2001
•[FIPS197]「Advanced Encryption Standard（AES）の仕様」。http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf、2001年11月26日。
•[Housley01] Planning for PKI, Russ Housley and Tim Polk, John Wiley & Sons, New York, 2001
•[Housley01]「PKIの計画」、Russ HousleyおよびTim Polk著、John Wiley & Sons、ニューヨーク、2001年。
•[Kuhn01] Introduction to Public Key Technology and the Federal PKI Infrastructure, Rick Kuhn, Vincent Hu, Tim Polk, and Shu-jen Chang, http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf, 26 February 2001
•[Kuhn01]「公開鍵技術および連邦PKI基盤の概要」、Rick Kuhn、Vincent Hu、Tim Polk、Shu-jen Chang著。http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf、2001年2月26日。
•[MUSTSHOULD] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997
•[MUSTSHOULD] Bradner, S.「RFCで要件レベルを示すために使用するキーワード」、BCP 14、RFC 2119、1997年3月。
•[MIME], RFC 1341, N. Borenstein, and N. Freed, Mechanisms for Specifying and Describing the Format of Internet Message Bodies, June 1992.
•[MIME] RFC 1341、N. BorensteinおよびN. Freed「インターネットメッセージ本文の形式を指定・記述する仕組み」、1992年6月。
•[PKCS #1], RSA Cryptography Standard, ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-1.asc, (See [RFC2313].)
•[PKCS #1]「RSA暗号化標準」。ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-1.asc（[RFC2313]を参照してください）。
•[RFC2313], RFC 2313, Kaliski, B., PKCS #1: RSA Encryption Version 1.5, March 1998
•[RFC2313] RFC 2313、Kaliski, B.「PKCS #1：RSA暗号化バージョン1.5」、1998年3月。
•[RFC2587], RFC 2587, Internet X.509 Public Key Infrastructure LDAPv2 Schema, S. Boeyen, T. Howes, P. Richard, June 1999
•[RFC2587] RFC 2587「インターネットX.509公開鍵基盤LDAPv2スキーマ」、S. Boeyen、T. Howes、P. Richard、1999年6月。
•[RFC2630], RFC 2630, Cryptographic Message Syntax, defines a cryptographic algorithm independent format for signed and encrypted data, June 1999
•[RFC2630] RFC 2630「暗号メッセージ構文」：署名付きデータおよび暗号化データのための、暗号アルゴリズムに依存しない形式を定義します。1999年6月。
•[RFC2631], RFC 2631, Diffie-Hellman Key Agreement Method, defines a variant of the Diffie-Hellman cryptographic algorithm as the mandatory key agreement method for S/MIME V3, June 1999
•[RFC2631] RFC 2631「Diffie-Hellman鍵共有方式」：S/MIME V3で必須の鍵共有方式として、Diffie-Hellman暗号アルゴリズムの変種を定義します。1999年6月。
•[RFC2632], RFC 2632, S/MIME Version 3 Certificate Handling, describes how an S/MIME V3 client uses public key infrastructure (PKI) to establish that a public key is valid, June 1999
•[RFC2632] RFC 2632「S/MIMEバージョン3の証明書処理」：S/MIME V3クライアントが公開鍵基盤（PKI）を用いて公開鍵の有効性を確認する方法を説明します。1999年6月。
•[RFC2633], RFC 2633, S/MIME Version 3 Message Specification, describes the protocol for adding cryptographic signature and encryption services to MIME data, June 1999
•[RFC2633] RFC 2633「S/MIMEバージョン3のメッセージ仕様」：MIMEデータに暗号署名および暗号化サービスを追加するプロトコルを説明します。1999年6月。
•[RFC 2634], RFC 2634, Enhanced Security Services for S/MIME, describes four optional security service extensions: signed receipts; security labels; secure mailing lists; and signing certificates, June 1999
•[RFC 2634] RFC 2634「S/MIMEの拡張セキュリティサービス」：署名付き受領通知、セキュリティラベル、セキュアメーリングリスト、署名証明書という4つの任意のセキュリティサービス拡張を説明します。1999年6月。
•[RFC3217], RFC3217, Triple-DES and RC2 Key Wrapping, September, 2001
•[RFC3217] RFC 3217「Triple-DESおよびRC2の鍵ラッピング」、2001年9月。
•[RFC3280], RFC3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, R. Housley, W. Polk, W. Ford, and D. Solo, April 2002.
•[RFC3280] RFC 3280「インターネットX.509公開鍵基盤の証明書および証明書失効リスト（CRL）プロファイル」、R. Housley、W. Polk、W. Ford、D. Solo、2002年4月。
•[RFC3394], Advanced Encryption Standard (AES) Key Wrap Algorithm, J. Schaad, R. Housley, September 2002.
•[RFC3394]「Advanced Encryption Standard（AES）鍵ラップアルゴリズム」、J. Schaad、R. Housley、2002年9月。
•[X.208], CCITT Recommendation X.208 (1988) | ISO/IEC 8824:1990, Information technology – Abstract Syntax Notation One (ASN.1): Specification of Basic Notation, 1988
•[X.208] CCITT勧告X.208（1988）｜ISO/IEC 8824:1990「情報技術―抽象構文記法1（ASN.1）：基本記法仕様」、1988年。
•[X.209] CCITT. Recommendation X.209 (1988) | ISO/IEC 8825:1990, Information technology – Abstract Syntax Notation One (ASN.1): Specification of Basic Encoding Rules (BER), 1990
•[X.209] CCITT勧告X.209（1988）｜ISO/IEC 8825:1990「情報技術―抽象構文記法1（ASN.1）：基本符号化規則（BER）」、1990年。
•[X.690], ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, Information technology – Abstract Syntax Notation One (ASN.1): Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), December 1997
•[X.690] ITU-T勧告X.690（1997）｜ISO/IEC 8825-1:1998「情報技術―抽象構文記法1（ASN.1）：基本符号化規則（BER）、正準符号化規則（CER）、識別符号化規則（DER）」、1997年12月。
•[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997.
•[X.509] ITU-T勧告X.509（1997 E）「情報技術―開放型システム間相互接続―ディレクトリ：認証フレームワーク」、1997年6月。
Note: All RFCs and Internet-Drafts are available from the IETF at http://www.ietf.org/rfc.html and http://www.ietf.org/ID.html, respectively.
注：すべてのRFCおよびInternet-Draftは、それぞれIETFの http://www.ietf.org/rfc.html および http://www.ietf.org/ID.html から入手できます。
A. Appendix A Cryptographic Algorithms (Non-Normative)
A. 付属書A 暗号アルゴリズム（参考情報）
The availability and implementation of cryptographic algorithms affect both the security and interoperability of S/MIME implementations. If a message is hashed or signed with an algorithm not supported by the recipient, the recipient cannot verify the signature. If the symmetric key (for message encryption) is derived or transferred with a key management algorithm not supported by the recipient, the recipient will not be able to recover the symmetric key and decrypt the message. If a message is encrypted with a symmetric algorithm not supported by the recipient, the recipient will not be able to recover the clear text.
暗号アルゴリズムが利用可能かどうか、また実装されているかどうかは、S/MIME実装のセキュリティと相互運用性の両方に影響します。受信者が対応していないアルゴリズムでメッセージがハッシュ化または署名されている場合、受信者は署名を検証できません。メッセージ暗号化用の共通鍵が、受信者の対応していない鍵管理アルゴリズムで導出または転送された場合、受信者は共通鍵を復元してメッセージを復号できません。受信者が対応していない共通鍵アルゴリズムでメッセージが暗号化された場合、受信者は平文を復元できません。
In addition, cryptographic algorithms offer different levels of protection [ORMAN]. Users of S/MIME products need to make their systems resistant to some predetermined level of attack. That level-of-attack resistance is the strength of the system. The one-way hash algorithm, digital signature algorithm, key management algorithm, and symmetric algorithm SHOULD be at least as strong as the system strength requirements.
さらに、暗号アルゴリズムによって保護強度は異なります[ORMAN]。S/MIME製品の利用者は、システムを所定の攻撃レベルに耐えられるようにする必要があります。この攻撃耐性のレベルがシステム強度です。一方向ハッシュアルゴリズム、デジタル署名アルゴリズム、鍵管理アルゴリズム、および共通鍵アルゴリズムは、システム強度要件以上の強度を備える SHOULD。
Selecting and matching appropriate cryptographic algorithms is a complex task. This document identifies algorithms that offer currently viable levels of security and identifies suites of algorithms that may be used together.
適切な暗号アルゴリズムを選択し、組み合わせる作業は複雑です。本書では、現時点で実用可能なセキュリティレベルを提供するアルゴリズムを特定し、併用可能なアルゴリズム一式を示します。
To help ensure that cryptographic functions are correctly implemented, software modules implementing cryptographic functions MUST conform to either FIPS 140-1 or to FIPS 140-2, Security Requirements For Cryptographic Modules [FIPS140-1] [FIPS140-2] as specified in Clause 2.1.1 of this profile.
暗号機能が正しく実装されるよう、暗号機能を実装するソフトウェアモジュールは、本プロファイルの2.1.1項に従い、FIPS 140-1またはFIPS 140-2「暗号モジュールのセキュリティ要件」[FIPS140-1] [FIPS140-2]に適合しなければなりません（MUST）。
A.1 One-Way Hash Algorithms
A.1 一方向ハッシュアルゴリズム
Hash algorithms map arbitrarily long inputs into a fixed-size output such that it is very difficult (computationally infeasible) to find two different hash inputs that produce the same output. Such algorithms are an essential part of the process of producing fixed-size digital signatures that can both authenticate the signer and provide for data integrity checking (detection of input modification after signature) in a S/MIME message. For S/MIME V3, the following hash algorithms are identified:
ハッシュアルゴリズムは、任意の長さの入力を固定サイズの出力に変換し、同じ出力を生成する異なる入力を見つけることが極めて困難（計算上実行不可能）となるようにします。このようなアルゴリズムは、署名者の認証とデータ完全性の確認（署名後に入力が改変されたことの検出）の両方を可能にする固定サイズのデジタル署名を、S/MIMEメッセージで生成するうえで不可欠です。S/MIME V3では、次のハッシュアルゴリズムを指定します。
SHA-1: S/MIME agents MUST support the Secure Hash Algorithm (SHA-1) as specified in [FIPS180-1] in agreement with Clause 2.1.1.1 of this profile.
SHA-1：S/MIMEエージェントは、[FIPS180-1]で規定されるセキュアハッシュアルゴリズム（SHA-1）を、本プロファイルの2.1.1.1項に従ってサポートしなければなりません（MUST）。
SHA-256: This enhanced secure hash algorithm has been published. When it becomes widely available, S/MIME agents SHOULD be capable of using [FIPS180-2].
SHA-256：この強化版セキュアハッシュアルゴリズムは公開済みです。広く利用可能になった時点で、S/MIMEエージェントは[FIPS180-2]で規定される方式を使用できるようにすべきです（SHOULD）。
A.2 Symmetric Encryption Algorithms
A.2 共通鍵暗号アルゴリズム
Symmetric encryption algorithms use the same secret key for data encryption and decryption. The Data Encryption Standard (DES) [FIPS46-3] algorithm using 56-bit keys has been available since the late 1970s and is now considered weak. The much stronger Advanced Encryption Standard (AES) [FIPS197] algorithm allowing up to 256-bit keys has recently been approved and implementations are expected to be widely available soon. In the interim, the triple DES algorithm, which uses multiple passes of the DES algorithm (significantly stronger than DES) is specified for use within S/MIME V3. Thus for S/MIME V3, the following symmetric encryption algorithms are identified:
共通鍵暗号アルゴリズムは、データの暗号化と復号に同じ秘密鍵を用います。56ビット鍵を用いるデータ暗号化標準（DES）[FIPS46-3]アルゴリズムは1970年代後半から利用可能であり、現在は弱いとみなされています。最大256ビット鍵を使用できる、より強力なAdvanced Encryption Standard（AES）[FIPS197]アルゴリズムは最近承認され、実装が近く広く利用可能になると見込まれます。それまでの間、DESアルゴリズムを複数回適用するTriple DES（DESより大幅に強力）がS/MIME V3での使用向けに規定されています。したがって、S/MIME V3では次の共通鍵暗号アルゴリズムを指定します。
3DES: The Triple DES algorithm [FIPS46-3] for encryption and decryption MUST be supported by sending and receiving agents as specified in Clause 2.1.1.1 of this profile. When generating messages, at least two independent keys MUST be supported. The Cipher Block Chaining Mode (CBC) MUST be supported. This algorithm is also known as DES EDE3 CBC.
3DES：送信側および受信側のエージェントは、本プロファイルの2.1.1.1項に従い、暗号化および復号に用いるTriple DESアルゴリズム[FIPS46-3]をサポートしなければなりません（MUST）。メッセージ生成時には、少なくとも独立した2つの鍵をサポートしなければなりません（MUST）。Cipher Block Chaining（CBC）モードをサポートしなければなりません（MUST）。このアルゴリズムはDES EDE3 CBCとも呼ばれます。
AES: The Cipher Block Chaining (CBC) mode of the Advanced Encryption Standard [FIPS197] with 128-bit keys SHOULD be supported by sending and receiving agents when it becomes widely available. (See Clause 2.1.1.2.)
AES：広く利用可能になった時点で、送信側および受信側のエージェントは、128ビット鍵を用いるAdvanced Encryption Standard [FIPS197]のCipher Block Chaining（CBC）モードをサポートすべきです（SHOULD）。（2.1.1.2項を参照してください。）
A.3 Digital Signature Algorithms
A.3 デジタル署名アルゴリズム
Digital signature algorithms are asymmetric (using public-private key pairs) algorithms that are used for digitally signing data. Use of signature algorithms in S/MIME V3 provides authentication, message integrity, and non-repudiation of origin. For S/MIME V3, the following digital signature algorithms are identified:
デジタル署名アルゴリズムは、データへのデジタル署名に用いる非対称（公開鍵と秘密鍵のペアを使用する）アルゴリズムです。S/MIME V3で署名アルゴリズムを用いることで、認証、メッセージ完全性、送信元の否認防止を実現できます。S/MIME V3では、次のデジタル署名アルゴリズムを指定します。
RSA: The RSA Public Key digital signature algorithm identified in [RFC2313] MUST be supported in combination with the SHA-1 hash algorithm as specified in Clause 2.1.1.1 of this profile.
RSA：[RFC2313]で特定されるRSA公開鍵デジタル署名アルゴリズムは、本プロファイルの2.1.1.1項に規定されるとおり、SHA-1ハッシュアルゴリズムと組み合わせてサポートしなければなりません（MUST）。
DSA: The DSA algorithm defined in [FIPS186-2] MUST be supported in combination with the SHA-1 hash algorithm as specified in Clause 2.1.1.1 of this profile.
DSA：[FIPS186-2]で定義されるDSAアルゴリズムは、本プロファイルの2.1.1.1項に規定されるとおり、SHA-1ハッシュアルゴリズムと組み合わせてサポートしなければなりません（MUST）。
rDSA: Implementations MAY support digital signatures using reversible public key cryptography (rDSA) as defined in [ANSIX9.31]
rDSA：実装は、[ANSIX9.31]で定義される可逆公開鍵暗号（rDSA）を用いたデジタル署名をサポートしてもよいです（MAY）。
ECDSA: Implementations MAY support elliptic curve digital signatures as defined in [ANSIX9.62].
ECDSA：実装は、[ANSIX9.62]で定義される楕円曲線デジタル署名をサポートしてもよいです（MAY）。
Note: Currently no standard methods (e.g., appropriate algorithm identifying OIDs) are defined for using rDSA or ECDSA with S/MIME.
注：現時点では、S/MIMEでrDSAまたはECDSAを使用するための標準方式（例：アルゴリズムを識別する適切なOID）は定義されていません。
A.4 Key Management Algorithms
A.4 鍵管理アルゴリズム
Key management algorithms are used for either key transport or for key agreement in a secure manner.
鍵管理アルゴリズムは、安全な方法で鍵を転送する場合、または鍵を共有する場合に使用されます。
The following key management algorithms are identified:
次の鍵管理アルゴリズムを指定します。
RSA (RFC2313): The RSA key exchange algorithm identified in [RFC2313] MUST be supported as specified in Clause 2.1.1.1 of this profile.
RSA（RFC2313）：[RFC2313]で特定されるRSA鍵交換アルゴリズムは、本プロファイルの2.1.1.1項に従ってサポートしなければなりません（MUST）。
Diffie-Hellman: Implementations SHOULD support the Diffie-Hellman Key Agreement method as defined in [RFC2631] as specified in Clause 2.1.1.2 of this profile.
Diffie-Hellman：実装は、本プロファイルの2.1.1.2項に規定されるとおり、[RFC2631]で定義されたDiffie-Hellman鍵共有方式をサポートすべきです（SHOULD）。
RSA (X9.44): The RSA Key Exchange Algorithm identified in [ANSIX9.44] MAY be supported.
RSA（X9.44）：[ANSIX9.44]で特定されるRSA鍵交換アルゴリズムは、サポートしてもよいです（MAY）。
Elliptic Curve Diffie-Hellman (X9.63): The Elliptic Curve Diffie-Hellman Key Agreement Algorithm identified in X9.63 [ANSIX9.63] MAY be supported.
楕円曲線Diffie-Hellman（X9.63）：X9.63 [ANSIX9.63]で特定される楕円曲線Diffie-Hellman鍵共有アルゴリズムは、サポートしてもよいです（MAY）。
Note: Currently no standard methods are defined for using RSA (X9.44) or Elliptic Curve Diffie-Hellman (X9.63) with S/MIME.
注：現時点では、S/MIMEでRSA（X9.44）または楕円曲線Diffie-Hellman（X9.63）を使用する標準方式は定義されていません。
A.5 Algorithm Suites
A.5 アルゴリズムスイート
Secure Hash Algorithms (Message Digest Algorithms), Symmetric Encryption Algorithms, Digital Signature Algorithms, and Key Management Algorithms are used together in algorithm suites to provide a full set of cryptographic security services for S/MIME. Each algorithm suite contains one of each of the cryptographic algorithm types to provide the cryptographic services. It is important that all of the components of each suite provide comparable protection against cryptographic attack. The following list of algorithm suites is identified for use within S/MIME V3:
セキュアハッシュアルゴリズム（メッセージダイジェストアルゴリズム）、共通鍵暗号アルゴリズム、デジタル署名アルゴリズム、および鍵管理アルゴリズムは、S/MIMEに必要な暗号セキュリティサービス一式を提供するため、アルゴリズムスイートとして組み合わせて使用されます。各アルゴリズムスイートには、暗号サービスを提供するため、各種類の暗号アルゴリズムが1つずつ含まれます。各スイートの構成要素すべてが、暗号攻撃に対して同程度の保護を提供することが重要です。S/MIME V3で使用するアルゴリズムスイートを次に示します。
SHA-1 hash algorithm, RSA (RFC 2313) for digital signature, RSA (RFC 2313) for key transport, Triple-DES [FIPS46-3] for content encryption. Implementations of S/MIME V3 MUST support this suite of algorithms. (See Clause 2.1.1.1.)
SHA-1ハッシュアルゴリズム、デジタル署名用RSA（RFC 2313）、鍵転送用RSA（RFC 2313）、コンテンツ暗号化用Triple-DES [FIPS46-3]。S/MIME V3の実装は、このアルゴリズムスイートをサポートしなければなりません（MUST）。（2.1.1.1項を参照してください。）
SHA-1 hash algorithm, DSA for digital signature, RSA (RFC 2313) for key transport, Triple-DES for content encryption. Implementations of S/MIME V3 MUST support this suite of algorithms. (See Clause 2.1.1.1.)
SHA-1ハッシュアルゴリズム、デジタル署名用DSA、鍵転送用RSA（RFC 2313）、コンテンツ暗号化用Triple-DES。S/MIME V3の実装は、このアルゴリズムスイートをサポートしなければなりません（MUST）。（2.1.1.1項を参照してください。）
SHA-1 hash algorithm, DSA for digital signature, Diffie-Hellman (RFC2631) for key agreement, Triple-DES for content encryption. Implementations of S/MIME V3 SHOULD support this suite of algorithms. (See Clause 2.1.1.2.)
SHA-1ハッシュアルゴリズム、デジタル署名用DSA、鍵共有用Diffie-Hellman（RFC2631）、コンテンツ暗号化用Triple-DES。S/MIME V3の実装は、このアルゴリズムスイートをサポートすべきです（SHOULD）。（2.1.1.2項を参照してください。）
SHA-1 hash algorithm, rDSA for digital signature, RSA [ANSIX9.44] for key transport, Triple-DES for content encryption. Implementations of S/MIME V3 MAY support this suite of algorithms.
SHA-1ハッシュアルゴリズム、デジタル署名用rDSA、鍵転送用RSA [ANSIX9.44]、コンテンツ暗号化用Triple-DES。S/MIME V3の実装は、このアルゴリズムスイートをサポートしてもよいです（MAY）。
SHA-1 hash algorithm, ECDSA for digital signature, ECDH for key agreement, Triple-DES for content encryption. Implementations of S/MIME V3 MAY support this suite of algorithms.
SHA-1ハッシュアルゴリズム、デジタル署名用ECDSA、鍵共有用ECDH、コンテンツ暗号化用Triple-DES。S/MIME V3の実装は、このアルゴリズムスイートをサポートしてもよいです（MAY）。
Recommendations: (These recommendations also appear in Clause 2.1.1.2.)
推奨事項：（これらの推奨事項は2.1.1.2項にも記載されています。）
•If an implementation supports AES, the implementation SHOULD also support RSA public key sizes greater than 1024 bits.
•実装がAESをサポートする場合、1024ビットを超えるRSA公開鍵サイズもサポートする SHOULD。
•If an implementation supports AES and D-H, the implementation SHOULD also support D-H public key sizes greater than 1024 bits.
•実装がAESとD-Hをサポートする場合、1024ビットを超えるD-H公開鍵サイズもサポートする SHOULD。
•If an implementation supports RSA or DSA public key sizes greater than 1024 bits, the implementation SHOULD also support SHA-256.
•実装が1024ビットを超えるRSAまたはDSA公開鍵サイズをサポートする場合、SHA-256もサポートする SHOULD。
Additional algorithm suites may be identified in the future as advanced algorithms including AES, SHA-256, and extended versions of DSA emerge.
AES、SHA-256、拡張版DSAなどの高度なアルゴリズムが登場すれば、将来、追加のアルゴリズムスイートが特定される場合があります。