Internet Engineering Task Force (IETF) D. K. Gillmor, Ed.
Request for Comments: 9787 ACLU
Category: Informational A. Melnikov, Ed.
ISSN: 2070-1721 Isode Ltd
B. Hoeneisen, Ed.
pEp Project
August 2025
End-to-end cryptographic protections for email messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for Mail User Agent (MUA) implementers to help mitigate those risks and to make end-to-end email simple and secure for the end user. It provides a useful set of vocabulary as well as recommendations to avoid common failures. It also identifies a number of currently unsolved usability and interoperability problems.
End-to-end cryptographic protections for email messages can provide useful security.ただし、暗号化保護を提供するための基準は非常に柔軟です。その柔軟性は、ユーザーをトラップし、驚くべき失敗を引き起こす可能性があります。このドキュメントでは、メールユーザーエージェント（MUA）の実装者がこれらのリスクを軽減し、エンドツーエンドの電子メールをエンドユーザーにとって簡単で安全にするためのガイダンスを提供します。一般的な障害を回避するための推奨事項だけでなく、ボキャブラリーの有用なセットを提供します。また、現在未解決のユーザー性と相互運用性の問題を多く識別します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9787.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9787で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
1.1.1. Structural Header Fields
1.1.2. User-Facing Header Fields
2. Usability
2.1. Simplicity
2.2. Email Users Want a Familiar Experience
2.3. Warning About Failure vs. Announcing Success
3. Types of Protection
3.1. Simplified Mental Model
3.2. One Cryptographic Status per Message
4. Cryptographic MIME Message Structure
4.1. Cryptographic Layers
4.1.1. S/MIME Cryptographic Layers
4.1.2. PGP/MIME Cryptographic Layers
4.2. Cryptographic Envelope
4.3. Cryptographic Payload
4.4. Types of Cryptographic Envelope
4.4.1. Simple Cryptographic Envelopes
4.4.2. Multilayer Cryptographic Envelopes
4.5. Errant Cryptographic Layers
4.5.1. Mailing List Wrapping
4.5.2. A Baroque Example
4.6. Cryptographic Summary
5. Message Composition
5.1. Message Composition Algorithm
5.2. Encryption Outside, Signature Inside
5.3. Avoid Offering Encrypted-Only Messages
5.4. Composing a Reply Message
6. Message Interpretation
6.1. Rendering Well-Formed Messages
6.2. Errant Cryptographic Layers
6.2.1. Errant Signing Layer
6.2.2. Errant Encryption Layer
6.2.3. Avoiding Non-MIME Cryptographic Mechanisms
6.3. Forwarded Messages with Cryptographic Protection
6.4. Signature Failures
6.5. Weak Encryption
7. Reasoning about Message Parts
7.1. Main Body Part
7.2. Attachments
7.3. MIME Part Examples
8. Certificate Management
8.1. Peer Certificates
8.1.1. Peer Certificate Selection
8.2. Local Certificates
8.2.1. Getting Certificates for the User
8.2.2. Local Certificate Maintenance
8.2.3. Shipping Certificates in Outbound Messages
9. Common Pitfalls and Guidelines
9.1. Reading Sent Messages
9.2. Reading Encrypted Messages after Certificate Expiration
9.3. Unprotected Message Header Fields
9.4. Composing an Encrypted Message with Bcc
9.4.1. Simple Encryption with Bcc
9.5. Draft Messages
9.6. Composing a Message to Heterogeneous Recipients
9.7. Message Transport Protocol Proxy: A Dangerous
Implementation Choice
9.7.1. Dangers of a Submission Proxy for Message Composition
9.7.2. Dangers of an IMAP Proxy for Message Rendering
9.7.3. Who Controls the Proxy?
9.8. Intervening MUAs Do Not Handle End-to-End Cryptographic
Protections
9.9. External Subresources in MIME Parts Break Cryptographic
Protections
10. IANA Considerations
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Future Work
A.1. Webmail Threat Model
A.2. Test Vectors
A.3. Further Guidance on Peer Certificates
A.3.1. Certificate Discovery from Incoming Messages
A.3.2. Certificate Directories
A.3.3. Checking for Certificate Revocation
A.3.4. Further Peer Certificate Selection
A.3.5. Human-Readable Names in Peer Certificates, Header
Fields, and Address Books
A.4. Further Guidance on Local Certificates and Secret Keys
A.4.1. Cross-MUA Sharing of Local Certificates and Secret Keys
A.4.2. Use of Smart Cards or Other Portable Secret Key
Mechanisms
A.4.3. Active Local Certificate Maintenance
A.5. Certification Authorities
A.6. Indexing and Search of Encrypted Messages
A.7. Cached Signature Validation
A.8. Aggregate Cryptographic Status
A.9. Expectations of Cryptographic Protection
A.10. Secure Deletion
A.11. Interaction with Opportunistic Encryption
A.12. Split Attachments
A.13. Proxy Extensions
A.14. Mailing Lists
Acknowledgements
Authors' Addresses
End-to-end email security using S/MIME [RFC8551] and PGP/MIME (Pretty Good Privacy with MIME) [RFC3156] cryptographic standards can provide integrity, authentication, and confidentiality to MIME [RFC4289] email messages.
S/MIME [RFC8551]およびPGP/MIME（MIMEを使用したかなり良いプライバシー）[RFC3156]暗号標準を使用したエンドツーエンドの電子メールセキュリティは、MIME [RFC4289]メールメッセージに完全性、認証、および機密性を提供できます。
However, there are many ways that an MUA handling such a message can misinterpret or accidentally break these security guarantees. For example, as described in [EFAIL], the "Direct Exfiltration" attack leaks cleartext due to an attack that splices existing ciphertext into a new message, which is then handled optimistically (and wrongly) by many MUAs.
ただし、このようなメッセージを処理するMUAがこれらのセキュリティ保証を誤って解釈したり、誤って破ったりすることができる多くの方法があります。たとえば、[eFail]で説明されているように、「直接剥離」攻撃は、既存の暗号文が新しいメッセージにスプリースする攻撃によりクリアテキストを漏らします。
A MUA that interprets a message with end-to-end cryptographic protections needs to do so defensively, staying alert to different ways that these protections can be bypassed by mangling (either malicious or accidental) or a failed user experience.
エンドツーエンドの暗号化保護でメッセージを解釈するMUAは、守備的にそうする必要があり、これらの保護をマングリング（悪意または偶発的）またはユーザーエクスペリエンスの失敗によってバイパスできるようにさまざまな方法に注意を払う必要があります。
A MUA that generates a message with end-to-end cryptographic protections should be aware of these defensive interpretation strategies and should compose any new outbound message conservatively if they want the protections to remain intact.
エンドツーエンドの暗号化保護を備えたメッセージを生成するMUAは、これらの防御的解釈戦略を認識し、保護を無傷のままにしたい場合は、新しいアウトバウンドメッセージを控えめに作成する必要があります。
This document offers guidance to the implementer of a MUA that provides these cryptographic protections, whether for composing, interpreting, rendering, or replying to a message. An implementation that follows this guidance will provide its users with stronger and easier-to-understand security properties and will also offer more reliable interoperability for messages exchanged with other implementations.
このドキュメントは、メッセージの作成、解釈、レンダリング、または返信など、これらの暗号保護を提供するMUAの実装者にガイダンスを提供します。このガイダンスに続く実装により、ユーザーはより強力で理解しやすいセキュリティプロパティを提供し、他の実装と交換されるメッセージに対してより信頼性の高い相互運用性を提供します。
In Appendix A, this document also identifies a number of interoperability and usability concerns for end-to-end cryptographic email that have no current broadly accepted technical standard for resolution. One major area not covered in this document is the acquisition and long-term maintenance of cryptographic identity information and metadata across multiple MUAs controlled by the same user.
付録Aでは、このドキュメントでは、解決のために現在広く受け入れられている技術基準を持たないエンドツーエンドの暗号化メールの相互運用性とユーザビリティの懸念も特定しています。このドキュメントでカバーされていない主要な領域の1つは、同じユーザーが制御する複数のMUAにわたる暗号化のアイデンティティ情報とメタデータの獲得と長期的なメンテナンスです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
For the purposes of this document, we define the following concepts:
このドキュメントの目的のために、次の概念を定義します。
* The _Mail User Agent (MUA)_ is an email client.
* _mailユーザーエージェント（MUA）_は電子メールクライアントです。
* _Protection_ of message data refers to cryptographic encryption and/or signatures, providing confidentiality, authenticity, and/or integrity.
* メッセージデータの_Protection_は、暗号化の暗号化および/または署名を指し、機密性、信頼性、および/または整合性を提供します。
* _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic Payload_, _Cryptographic Summary_, and _Errant Cryptographic Layer_ are defined in Section 4.
* _cryptographic layer _、_cryptographic envelope_、_cryptographic payload _、_cryptographic summary_、_erant cryptographic layer_はセクション4で定義されています。
* A _well-formed_ email message with cryptographic protection has both a _Cryptographic Envelope_ and a _Cryptographic Payload_.
* 暗号化保護を備えた_Well-Formed_電子メールメッセージには、_cryptographic envelope_と_cryptographic Payload_の両方があります。
* _Structural Header Fields_ are documented in Section 1.1.1.
* _Structural Header Fields _はセクション1.1.1に文書化されています。
* _Non-Structural Header Fields_ are header fields that are not Structural Header Fields.
* _Non-structural Header Fields_は、構造ヘッダーフィールドではないヘッダーフィールドです。
* _User-Facing Header Fields_ are documented in Section 1.1.2.
* _User Facingヘッダーフィールド_は、セクション1.1.2に文書化されています。
* A _Main Body Part_ is any part of a message that is typically rendered to the user as the message itself (not "as an attachment"). See Section 7.1.
* _main body part_は、メッセージ自体としてユーザーにレンダリングされるメッセージの一部です（「添付ファイルとして」ではありません）。セクション7.1を参照してください。
This document contains extensive discussion about end-to-end cryptographic protections in email while acknowledging that many MUAs have no capabilities for end-to-end cryptographic protections at all. We divide MUAs into three distinct profiles:
このドキュメントには、多くのMUAにはエンドツーエンドの暗号保護の能力がないことを認めながら、電子メールのエンドツーエンドの暗号化保護に関する広範な議論が含まれています。MUASを3つの異なるプロファイルに分けます。
* A _non-cryptographic_ MUA has no capabilities for end-to-end cryptographic protections.
* _non-cryptographic_MUAには、エンドツーエンドの暗号化保護の能力がありません。
* A _conformant_ MUA follows the guidance in this document when dealing with end-to-end cryptographic protections.
* _CONFORMANT_ MUAは、エンドツーエンドの暗号化保護を扱う際に、このドキュメントのガイダンスに従います。
* A _legacy_ MUA has capabilities for end-to-end cryptographic protections but does not adhere to the guidance in this document.
* _Legacy_MUAには、エンドツーエンドの暗号化保護の能力がありますが、このドキュメントのガイダンスを順守していません。
At the time of the writing of this document, most MUAs with cryptographic protections are legacy MUAs.
この文書の執筆時点では、暗号化保護を備えたほとんどのMUAはレガシーMUAです。
A message header field named MIME-Version, or whose name begins with Content-, is referred to in this document as a "structural" header field. This is a less-ambiguous name for what [RFC2045] calls "MIME header fields".
Mime-versionという名前のメッセージヘッダーフィールド、またはその名前がコンテンツから始まるのは、このドキュメントでは「構造的な」ヘッダーフィールドと呼ばれます。これは、[RFC2045]が「Mime Header Fields」と呼んでいるものの、あまり曖昧でない名前です。
These header fields indicate something about the specific MIME part they are attached to and cannot be transferred or copied to other parts without endangering the readability of the message.
これらのヘッダーフィールドは、添付されている特定のMIME部分に関する何かを示しており、メッセージの読みやすさを危険にさらすことなく、他の部分に転送またはコピーすることはできません。
This includes:
これには次のものが含まれます。
* MIME-Version
* mime-version
* Content-Type
* コンテンツタイプ
* Content-Transfer-Encoding
* コンテンツトランスファーエンコード
* Content-Disposition
* コンテンツディスポジション
Of all the header fields that an email message may contain, only a small subset are typically presented directly to the user. This document refers to them as User-Facing Header Fields. Typically, User-Facing Header Fields are:
メールメッセージに含まれる可能性のあるすべてのヘッダーフィールドのうち、通常、小さなサブセットのみがユーザーに直接表示されます。このドキュメントは、それらをユーザー向けヘッダーフィールドと呼んでいます。通常、ユーザー向けヘッダーフィールドは次のとおりです。
* Subject
* 主題
* From
* から
* To
* に
* Cc
* CC
* Date
* 日付
* Reply-To
* 返信
* Followup-To
* フォローアップ
* Sender
* 送信者
* Resent-From
* resから
* Resent-To
* resります
* Resent-Cc
* Resent-CC
* Resent-Date
* resent-date
* Resent-Sender
* resしたセンダー
The above list contains the header fields most often presented directly to the user who views a message, though an MUA may also decide to treat any other header field as "User-Facing". Of course, many of these header fields are entirely absent from any given message, and an absent header field is not presented to the user at all.
上記のリストには、メッセージを表示するユーザーに直接提示されるヘッダーフィールドが含まれていますが、MUAは他のヘッダーフィールドを「ユーザー面」として扱うことも決定する場合があります。もちろん、これらのヘッダーフィールドの多くは、特定のメッセージに完全に存在しないため、ヘッダーフィールドの欠如はユーザーにはまったく表示されません。
Note that the resending header fields (those beginning with Resent-) are typically only added by an intervening MUA (see Section 3.6.6 of [RFC5322] and Section 9.8 of this document). As such, though they may in some cases be presented to the user, they will typically not bear any end-to-end cryptographic protection (even if the original header fields of a message are protected; see Section 9.3), because they are unknown to the original sender.
復活ヘッダーフィールド（res resから始まるもの）は通常、介在するMUAによってのみ追加されていることに注意してください（[RFC5322]のセクション3.6.6およびこのドキュメントのセクション9.8を参照）。そのため、場合によってはユーザーに提示される場合がありますが、通常、エンドツーエンドの暗号化保護を負いません（メッセージの元のヘッダーフィールドが保護されていても、セクション9.3を参照）。
Other header fields may affect the visible rendering of the message (e.g., References and In-Reply-To may affect the placement of a message in a threaded discussion, or the List-* and Archived-At header fields added by mailing lists may cause additional buttons to be displayed during rendering), but they are not directly displayed to the user and so are not considered "User-Facing".
他のヘッダーフィールドは、メッセージの目に見えるレンダリングに影響を与える可能性があります（例：参照や繰り返しは、スレンダー付きディスカッションでのメッセージの配置に影響を与える可能性があります。
Any MUA that enables its user to transition from unprotected messages to messages with end-to-end cryptographic protection needs to consider how the user understands this transition. That said, the primary goal of the user of an MUA is communication -- so interface elements that interfere with communication should be avoided where possible.
ユーザーが保護されていないメッセージからエンドツーエンドの暗号化保護を備えたメッセージに移行できるMUAは、ユーザーがこのトランジションをどのように理解しているかを検討する必要があります。とはいえ、MUAのユーザーの主な目標は通信です。そのため、可能な限り通信を妨げるインターフェイス要素を避ける必要があります。
Furthermore, it is a near certainty that the user will continue to encounter unprotected messages and may need to send unprotected messages (for example, if a given recipient cannot handle cryptographic protections). This means that the MUA needs to provide the user with some guidance so that they understand what protections any given message or conversation has. But the user should not be overwhelmed with choices or presented with unactionable information.
さらに、ユーザーが保護されていないメッセージに遭遇し続け、保護されていないメッセージを送信する必要がある場合があります（たとえば、特定の受信者が暗号化保護を処理できない場合）。これは、MUAがユーザーに何らかのガイダンスを提供する必要があることを意味し、特定のメッセージや会話がどのような保護にあるかを理解する必要があります。ただし、ユーザーは、選択肢に圧倒されたり、アクション不可能な情報を提示したりしないでください。
The end user (the operator of the MUA) is unlikely to understand complex end-to-end cryptographic protections on any email message, so keep it simple.
エンドユーザー（MUAのオペレーター）は、電子メールメッセージで複雑なエンドツーエンドの暗号化保護を理解する可能性は低いため、シンプルにしてください。
For clarity to the user, any cryptographic protections should apply to the message as a whole, not just to some subparts.
ユーザーを明確にするために、暗号化保護は、一部のサブパートだけでなく、メッセージ全体に適用する必要があります。
This is true for message composition: The standard message composition user interface of an MUA should offer minimal controls that indicate which types of protection to apply to the new message as a whole.
これはメッセージ構成に当てはまります。MUAの標準メッセージ構成ユーザーインターフェイスは、新しいメッセージ全体に適用する保護の種類を示す最小限のコントロールを提供する必要があります。
This is also true for message interpretation: The standard message rendering user interface of an MUA should offer a minimal, clear indicator about the end-to-end cryptographic status of the message as a whole.
これは、メッセージの解釈にも当てはまります。MUAのユーザーインターフェイスをレンダリングする標準メッセージは、メッセージ全体のエンドツーエンド暗号化ステータスについて最小限で明確なインジケーターを提供する必要があります。
See Section 3 for more details about mental models and cryptographic status.
メンタルモデルと暗号化ステータスの詳細については、セクション3を参照してください。
(It is of course possible that a message forwarded as a MIME attachment could have its own cryptographic status while still being a message subpart, but that status should be distinct from the status of the enclosing message.)
（もちろん、MIMEの添付ファイルとして転送されたメッセージは、メッセージサブパートである間に独自の暗号化ステータスを持つ可能性がありますが、そのステータスは囲まれたメッセージのステータスとは異なるはずです。）
A person communicating over the Internet today often has many options for reaching their desired correspondent, including web-based bulletin boards, contact forms, and instant messaging services.
今日インターネットで通信している人は、多くの場合、Webベースの掲示板、連絡先フォーム、インスタントメッセージングサービスなど、希望する特派員に到達するための多くのオプションがあります。
Email offers a few distinctions from these other systems, most notably features like:
電子メールは、これらの他のシステム、特に次のような機能からいくつかの区別を提供します。
Ubiquity:
遍在：
Most correspondents will have an email address, while not everyone is present on the various non-email messaging services, particularly those that have reliable end-to-end cryptographic protections.
ほとんどの特派員はメールアドレスを持っていますが、誰もがさまざまな非照度メッセージングサービス、特に信頼性の高いエンドツーエンドの暗号保護を備えたサービスに存在するわけではありません。
Federation:
フェデレーション：
Interaction between users on distinct domains who have not agreed on a common communications provider is still possible.
一般的な通信プロバイダーに合意していない異なるドメイン上のユーザー間の相互作用はまだ可能です。
User Control:
ユーザーコントロール：
The user can interact with the email system using an MUA of their choosing, including automation and other control over their preferred and/or customized workflow.
ユーザーは、選択したMUAを使用して電子メールシステムと対話できます。これには、自動化やその他のカスタマイズされたワークフローに対するその他の制御が含まれます。
Other systems (like some popular instant messaging applications, such as WhatsApp and Signal Private Messenger) offer built-in end-to-end cryptographic protections by default, which are simpler for the user to understand. ("All the messages I see on Signal are confidential and integrity-protected" is a clean user story.)
他のシステム（WhatsAppやSignal Private Messengerなどの人気のあるインスタントメッセージングアプリケーションなど）は、デフォルトで組み込みのエンドツーエンドの暗号化保護を提供します。これは、ユーザーが理解するのが簡単です。（「信号で表示されるすべてのメッセージは機密であり、整合性が保護されています」は、クリーンなユーザーストーリーです。）
A user of email is likely using email instead of other systems because of the distinctions outlined above. When adding end-to-end cryptographic protection to an email endpoint, care should be taken not to negate any of the distinct features of email as a whole. If these features are violated to provide end-to-end cryptographic protection, the user may just as well choose one of the other systems that don't have the drawbacks that email has. Implementers should try to provide end-to-end protections that retain the familiar experience of email itself.
電子メールのユーザーは、上記の区別があるため、他のシステムの代わりに電子メールを使用している可能性があります。電子メールエンドポイントにエンドツーエンドの暗号化保護を追加する場合、電子メール全体の明確な機能を無効にしないように注意する必要があります。これらの機能がエンドツーエンドの暗号化保護を提供するために違反されている場合、ユーザーは、電子メールが持っている欠点がない他のシステムのいずれかを選択することもできます。実装者は、電子メール自体の馴染みのあるエクスペリエンスを保持するエンドツーエンドの保護を提供しようとする必要があります。
Furthermore, an email user is likely to regularly interact with other email correspondents who _cannot_ handle or produce end-to-end cryptographic protections. Care should be taken when enabling cryptography in an MUA so that the MUA does not inadvertently limit the ability of the user to interact with correspondents who use legacy or non-cryptographic MUAs.
さらに、電子メールユーザーは、エンドツーエンドの暗号化保護を処理または作成する他の電子メール特派員と定期的に対話する可能性があります。MUAがMUAで暗号化を可能にして、MUAがレガシーまたは非暗号化MUAを使用する特派員と対話する能力を不注意に制限しないように注意する必要があります。
Moving the Web from http to https offers useful historical similarities to adding end-to-end encryption to email.
WebをHTTPからHTTPSに移動すると、エンドツーエンドの暗号化を電子メールに追加するのに役立つ歴史的な類似点が提供されます。
In particular, the indicators of what is "secure" vs. "insecure" for web browsers have changed over time. For example, years ago, the default experience was http, and https sites were flagged with "secure" indicators like a lock icon. Starting in 2018, some browsers reversed that process by downplaying https and instead visibly marking http as "not secure" (see [CHROME-INDICATORS]).
特に、Webブラウザーの「安全」対「不安」の指標は、時間の経過とともに変化しました。たとえば、数年前、デフォルトのエクスペリエンスはHTTPであり、HTTPSサイトにはロックアイコンのような「安全な」インジケーターがフラグが付けられていました。2018年以降、一部のブラウザはHTTPをダウンプレイし、代わりにHTTPを「安全ではない」と見えることでそのプロセスを逆転させました（[Chrome-Indicators]を参照）。
By analogy, when the user of an MUA first enables end-to-end cryptographic protection, it's likely that they will want to see which messages _have_ protection (that is, the security indicators amenable to a conformant MUA as of 2025 are most likely to be comparable to those of a pre-2018 web browser). But a user whose private email communications with a given correspondent, or within a given domain, are known to be entirely end-to-end protected might instead want to know which messages do _not_ have the expected protections.
類推により、MUAのユーザーが最初にエンドツーエンドの暗号保護を有効にすると、どのメッセージ_have_保護（つまり、2025年の適合MUAに適したセキュリティ指標が2018年以前のWeb Browserのものと比較可能）を確認したい可能性があります。しかし、特定の特派員または特定のドメイン内のプライベートメール通信が完全にエンドツーエンドの保護されていることが知られているユーザーは、代わりに、どのメッセージが期待される保護を持っているかを知りたい場合があります。
Note also that some messages may be expected to be confidential, but other messages are expected to be public -- the types of protection (see Section 3) that apply to each particular message will be different. And the types of protection that are _expected_ to be present in any context might differ (for example, by sender, by thread, or by date).
また、一部のメッセージは機密になると予想される場合がありますが、他のメッセージは公開されると予想されます。特定のメッセージに適用される保護の種類（セクション3を参照）は異なります。また、任意のコンテキストで存在する_expected_の保護の種類は異なる場合があります（たとえば、送信者、スレッド、または日付ごとに）。
It is out of scope for this document to define expectations about protections for any given message, but an implementer who cares about offering a simple user experience should be deliberate and judicious about the expectations their interface assumes that the user has in a given context. See Appendix A.9 for future work.
このドキュメントは、特定のメッセージの保護に関する期待を定義することは範囲外ですが、単純なユーザーエクスペリエンスを提供することを気にする実装者は、インターフェイスが特定のコンテキストで持っていると想定する期待について慎重かつ慎重にする必要があります。将来の作業については、付録A.9を参照してください。
A given message might be:
与えられたメッセージは次のとおりです。
* signed,
* 署名された、
* encrypted,
* 暗号化された、
* both signed and encrypted, or
* 署名と暗号化の両方、または
* none of the above.
* 上記のどれでもない。
Given that many email messages offer no cryptographic protections, the user needs to be able to detect which protections are present for any given message.
多くの電子メールメッセージが暗号化保護を提供していないことを考えると、ユーザーは特定のメッセージに対してどの保護が存在するかを検出できる必要があります。
To the extent that an email message actually does have end-to-end cryptographic protections, those protections need to be visible and comprehensible to the end users: both the composing user and the recipient who views the rendered message. If either user is unaware of the protections, then they do not effectively extend all the way to the "end".
電子メールメッセージが実際にエンドツーエンドの暗号化保護を持っている限り、これらの保護はエンドユーザーに目に見えるように理解できる必要があります。いずれかのユーザーが保護を認識していない場合、「終了」まで効果的に拡張しません。
However, most users do not have (or want to have) a sophisticated mental model of what kinds of protections can be associated with a given message. Even the four states above approach the limits of complexity for an interface for normal users.
ただし、ほとんどのユーザーは、特定のメッセージにどのような保護を関連付けることができるかという洗練されたメンタルモデルを持っていません（または持ちたい）。上記の4つの状態でさえ、通常のユーザーのインターフェイスの複雑さの限界に近づいています。
While Section 5.3 recommends avoiding deliberate creation of encrypted-only messages, some messages may end up in the encrypted-only state due to signature failure or certificate revocation.
セクション5.3では、暗号化のみのメッセージの意図的な作成を回避することを推奨していますが、一部のメッセージは、署名の失敗または証明書の取り消しにより、暗号化のみの状態になる可能性があります。
A simple model for the recipient could be that a message is in one of three normal states, which align with the only reasonable choices for message composition:
受信者の単純なモデルは、メッセージが3つの通常の状態のいずれかにあることであり、メッセージ構成の唯一の合理的な選択肢と一致する可能性があります。
* Unprotected
* 保護されていない
* Verified (has a valid signature from the apparent sender of the message)
* 検証（メッセージの見かけの送信者からの有効な署名があります）
* Confidential (encrypted with a valid signature from the apparent sender of the message)
* Confidential（メッセージの見かけの送信者からの有効な署名で暗号化）
However, one error state exists for rendered mail that does not correspond to a reasonable choice for message composition:
ただし、メッセージ構成の合理的な選択に対応しないレンダリングされたメールには、1つのエラー状態が存在します。
* Encrypted But Unverified (encrypted without a valid signature from the apparent sender of the message)
* 暗号化されたが未検証（メッセージの見かけの送信者からの有効な署名なしで暗号化）
Note that this last state is not "Confidential" (a secret shared exclusively between the participants in the communication) because the recipient does not know for sure who sent it.
この最後の状態は、受信者が誰がそれを送ったかを確実に知らないため、「コミュニケーションの参加者のみで共有される秘密」ではないことに注意してください。
In an ecosystem where encrypted-only messages are never deliberately sent (see Section 5.3), representing an Encrypted But Unverified message as a type of user-visible error is not unreasonable. However, this is not the state of the global email ecosystem when this document was written, since some legacy MUAs permit composing encrypted-but-unsigned mail (see Appendix A.9 for possible future guidance).
暗号化のみのメッセージが意図的に送信されることはないエコシステムでは（セクション5.3を参照）、ユーザー可視エラーの一種として暗号化されたが未確認のメッセージを表すことは不合理ではありません。ただし、これは、このドキュメントが記述されたときのグローバルメールエコシステムの状態ではありません。一部のレガシーMUASは、暗号化された郵便メールを作成することを許可しているためです（将来のガイダンスの可能性については、付録A.9を参照）。
Alternately, an MUA may prefer to represent the state of an Encrypted But Unverified message to the user as though it was Unprotected since no verification is possible. However the MUA represents the message to the user, it MUST NOT leak cleartext of an encrypted message (even an Encrypted But Unverified message) in subsequent replies (see Section 5.4) or similar replications of the message.
あるいは、MUAは、検証が不可能であるため、保護されていないかのように、暗号化されたが未検証のメッセージの状態をユーザーに表すことを好む場合があります。ただし、MUAはユーザーへのメッセージを表します。後続の返信（セクション5.4を参照）またはメッセージの同様の複製で暗号化されたメッセージ（暗号化されたが未確認のメッセージでさえ）のクリアテキストを漏らしてはなりません。
Note that a cleartext message with an invalid signature SHOULD NOT be represented to the user as anything other than Unprotected (see Section 6.4) unless the MUA is providing the user with debugging information.
無効な署名を持つクリアテキストメッセージは、MUAがユーザーにデバッグ情報を提供していない限り、保護されていない（セクション6.4を参照）以外のものとしてユーザーに表すべきではないことに注意してください。
At the time this document was written, the global email ecosystem contains a heterogeneous mix of legacy and non-cryptographic MUAs. In such an ecosystem, a conformant MUA may instead prefer to represent "Verified" and "Encrypted" as orthogonal states of any given rendered message. While this model does not precisely match the choice a user makes when composing a message, it may align more with the reality of the range of messages they encounter as a recipient.
このドキュメントが書かれた時点で、グローバルメールエコシステムには、レガシーと非暗号化MUAの不均一な組み合わせが含まれています。このような生態系では、適切なMUAは、代わりに、与えられたメッセージの直交状態として「検証」および「暗号化」を表すことを好む場合があります。このモデルは、メッセージを作成するときにユーザーが行う選択と正確に一致していませんが、受信者として遭遇するメッセージの範囲の現実とさらに整合する可能性があります。
Some MUAs may attempt to generate multiple copies of a given email message, with different copies offering different types of protection (for example, opportunistically encrypting on a per-recipient basis). A message resulting from this approach will have a cryptographic state that few users will understand. Even if the composer understands the different statuses of the different copies, the recipients of the messages may not understand (each recipient might not even know about the other copies). See, for example, the discussion in Section 9.6 for how this can go wrong.
一部のMUAは、特定の電子メールメッセージの複数のコピーを生成しようとする場合があります。さまざまなコピーがさまざまな種類の保護を提供します（たとえば、レシピエントごとに日和見的に暗号化する）。このアプローチに起因するメッセージには、ユーザーがほとんど理解できない暗号化状態があります。作曲家が異なるコピーのさまざまなステータスを理解していても、メッセージの受信者が理解できない場合があります（各受信者は他のコピーについてさえ知らないかもしれません）。たとえば、これがどのようにうまくいかないかについては、セクション9.6の議論を参照してください。
For comprehensibility, a conformant MUA SHOULD NOT create multiple copies of a given message that differ in the types of end-to-end cryptographic protections afforded.
包括性のために、コンフォーマントMUAは、与えられたエンドツーエンドの暗号化保護のタイプが異なる特定のメッセージの複数のコピーを作成してはなりません。
For opportunistic cryptographic protections that are not surfaced to the user (that is, that are not end-to-end), other mechanisms like transport encryption [RFC3207] or domain-based signing [RFC6376] may be preferable due to ease of implementation and deployment. These opportunistic transport protections are orthogonal to the end-to-end protections described in this document.
ユーザーに表面化されていない日和見的な暗号保護（つまり、エンドツーエンドではない）の場合、輸送暗号化[RFC3207]やドメインベースの署名[RFC6376]などの他のメカニズムが、実装と展開の容易さにより好ましい場合があります。これらの日和見的輸送保護は、この文書に記載されているエンドツーエンドの保護の直交です。
To the extent that opportunistic message protections are made visible to the user for a given copy of a message, a conformant MUA will distinguish that status from the message's end-to-end cryptographic status. But the potential confusion caused by rendering this complex, hybrid state may not be worth the value of additional knowledge gained by the user. The benefits of opportunistic protections accrue (or don't) even without visibility to the user (see [RFC7435]).
特定のメッセージのコピーに対して日和見メッセージ保護がユーザーに見える限り、コンフォーマントMUAは、そのステータスをメッセージのエンドツーエンドの暗号化ステータスと区別します。しかし、この複合体をレンダリングすることによって引き起こされる潜在的な混乱は、ハイブリッド状態がユーザーが獲得した追加の知識の価値の価値がないかもしれません。ユーザーへの可視性がなくても、日和見保護の利点は発生します（またはそうではありません）（[RFC7435]を参照）。
The user needs a single clear, simple, and correct indication about the end-to-end cryptographic status of any given message. See Section 4.6 for more details.
ユーザーは、特定のメッセージのエンドツーエンドの暗号化ステータスについて、1つの明確でシンプルで正しい兆候を必要とします。詳細については、セクション4.6を参照してください。
Implementations use the structure of an email message to establish (when composing) and understand (when rendering) the cryptographic status of the message. This section establishes some conventions about how to think about message structure.
実装は、電子メールメッセージの構造を使用して、メッセージの暗号化ステータスを確立し（作成するとき）（レンダリング時に）確立し、理解します。このセクションでは、メッセージ構造について考える方法に関するいくつかの慣習を確立します。
"Cryptographic Layer" refers to a MIME substructure that supplies some cryptographic protections to an internal MIME subtree. The internal subtree is known as the "protected part", though of course it may itself be a multipart object.
「暗号化層」とは、内部MIMEサブツリーにいくつかの暗号保護を供給するMIME下部構造を指します。内部サブツリーは「保護された部分」として知られていますが、もちろんそれ自体がマルチパートオブジェクトである可能性があります。
In the diagrams below, "╧" (BOX DRAWINGS UP SINGLE AND HORIZONTAL DOUBLE, U+2567) indicates "decrypts to" and "┴" (BOX DRAWINGS LIGHT UP AND HORIZONTAL, U+2534) indicates "unwraps to".
以下の図では、「╧」（ボックスの図面がシングルおよび水平二重、u+2567）を「decrypts」と「┴」（ボックス図面が明るく、水平、u+2534）を「box drawings unwraps」を示します。
For S/MIME [RFC8551], there are four forms of Cryptographic Layers: multipart/signed, PKCS #7 signed-data, PKCS #7 enveloped-data, and PKCS #7 authEnveloped-data.
S/MIME [RFC8551]の場合、マルチパート/署名、PKCS＃7の署名型デイタ、PKCS＃7エンベロープデータ、およびPKCS＃7 Authenveloped-Dataの4つの形式には、4つの形式の暗号化層があります。
└┬╴multipart/signed; protocol="application/pkcs7-signature"
├─╴[protected part]
└─╴application/pkcs7-signature
This MIME layer offers authentication and integrity.
このマイム層は、認証と完全性を提供します。
└┬╴application/pkcs7-mime; smime-type="signed-data"
┴ (unwraps to)
└─╴[protected part]
This MIME layer offers authentication and integrity.
このマイム層は、認証と完全性を提供します。
└┬╴application/pkcs7-mime; smime-type="enveloped-data"
╧ (decrypts to)
└─╴[protected part]
This MIME layer offers confidentiality.
このマイム層は機密性を提供します。
└┬╴application/pkcs7-mime; smime-type="authEnveloped-data"
╧ (decrypts to)
└─╴[protected part]
This MIME layer offers confidentiality and integrity.
このマイム層は、機密性と誠実さを提供します。
Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data (Section 4.1.1.4) have identical message structures and very similar confidentiality semantics. The only difference between the two is ciphertext malleability.
封筒（セクション4.1.1.3）およびAuthenveloped-Data（セクション4.1.1.4）には、同一のメッセージ構造と非常に類似した機密保持セマンティクスがあることに注意してください。この2つの唯一の違いは、暗号文脈の順形性です。
The examples in this document only include enveloped-data, but the implications for that layer apply to authEnveloped-data as well.
このドキュメントの例には、封筒のデータのみが含まれていますが、その層への影響は、認定されたデータにも適用されます。
The Cryptographic Message Syntax (CMS) provides a MIME compression layer (smime-type="compressed-data"), as defined in [RFC3274]. While the compression layer is technically a part of CMS, it is not considered a Cryptographic Layer for the purposes of this document.
[RFC3274]で定義されているように、暗号化メッセージの構文（CMS）は、MIME圧縮層（SMIME-Type = "圧縮-Data"）を提供します。圧縮層は技術的にはCMSの一部ですが、このドキュメントの目的のための暗号化層とは見なされません。
For PGP/MIME [RFC3156], there are two forms of Cryptographic Layers: signing and encryption.
PGP/MIME [RFC3156]の場合、署名と暗号化の2つの形式の暗号化層があります。
└┬╴multipart/signed; protocol="application/pgp-signature"
├─╴[protected part]
└─╴application/pgp-signature
This MIME layer offers authenticity and integrity.
このマイム層は、信頼性と誠実さを提供します。
└┬╴multipart/encrypted
├─╴application/pgp-encrypted
└┬╴application/octet-stream
╧ (decrypts to)
└─╴[protected part]
This MIME layer can offer:
このマイム層は提供できます：
* confidentiality (via a Symmetrically Encrypted Data Packet, see Section 5.7 of [RFC9580]; an MUA MUST NOT generate this form due to ciphertext malleability),
* 機密性（対称的に暗号化されたデータパケットを介して、[RFC9580]のセクション5.7を参照してください。MUAは、暗号文化障害のためにこのフォームを生成してはなりません）、
* confidentiality and integrity (via a Symmetrically Encrypted and Integrity Protected Data Packet (SEIPD); see Section 5.13 of [RFC9580]), or
* 機密性と整合性（対称的に暗号化され、整合性保護されたデータパケット（SEIPD）を介して、[RFC9580]のセクション5.13を参照）、または
* confidentiality, integrity, and authenticity all together (by including an OpenPGP Signature Packet, see Section 5.2 of [RFC9580], within the SEIPD).
* 機密性、完全性、および信頼性はすべて一緒になります（OpenPGP署名パケットを含めることにより、SEIPD内の[RFC9580]のセクション5.2を参照）。
The Cryptographic Envelope is the largest contiguous set of Cryptographic Layers of an email message starting with the outermost MIME type (that is, with the Content-Type of the message itself).
暗号化エンベロープは、最も外側のmimeタイプ（つまり、メッセージ自体のコンテンツタイプを使用して）から始まる電子メールメッセージの暗号化層の最大の隣接するセットです。
If the Content-Type of the message itself is not a Cryptographic Layer, then the message has no Cryptographic Envelope.
メッセージ自体のコンテンツタイプが暗号化層ではない場合、メッセージには暗号化封筒がありません。
"Contiguous" in the definition above indicates that if a Cryptographic Layer is the protected part of another Cryptographic Layer, the layers together comprise a single Cryptographic Envelope.
上記の定義の「隣接」は、暗号化層が別の暗号層の保護された部分である場合、層が一緒になって単一の暗号エンベロープを含むことを示しています。
Note that if a non-Cryptographic Layer intervenes, all Cryptographic Layers within the non-Cryptographic Layer _are not_ part of the Cryptographic Envelope. They are Errant Cryptographic Layers (see Section 4.5).
非暗号化層が介入する場合、非暗号化層内のすべての暗号化層_は、暗号エンベロープの一部ではありません。それらは誤った暗号層です（セクション4.5を参照）。
Also note that the ordering of the Cryptographic Layers implies different cryptographic properties. A signed-then-encrypted message is different than an encrypted-then-signed message. See Section 5.2.
また、暗号化層の順序は、異なる暗号化特性を意味することに注意してください。署名済みのテン暗号化されたメッセージは、暗号化された細かい署名メッセージとは異なります。セクション5.2を参照してください。
The Cryptographic Payload of a message is the first non-Cryptographic Layer -- the "protected part" -- within the Cryptographic Envelope.
メッセージの暗号化ペイロードは、暗号化された封筒内の最初の非暗号化層（「保護された部分」）です。
As described above, if the "protected part" identified in the section above is not itself a Cryptographic Layer, that part _is_ the Cryptographic Payload.
上記のように、上記のセクションで識別された「保護された部分」が暗号化層ではない場合、その部分は暗号化ペイロードです。
If the application wants to generate a message that is both encrypted and signed, it MAY use the simple MIME structure from Section 4.1.2.2 by ensuring that the [RFC9580] Encrypted Message within the application/octet-stream part contains a [RFC9580] Signed Message (the final option described in Section 4.1.2.2).
アプリケーションが暗号化および署名の両方のメッセージを生成したい場合、[RFC9580]がアプリケーション/オクテットストリームパーツ内の暗号化されたメッセージが[RFC9580]に署名されたメッセージ（セクション4.1.2.2に記載されている最終オプション）を含むことを保証することにより、セクション4.1.2.2の単純なMIME構造を使用する場合があります。
It is possible to construct a Cryptographic Envelope consisting of multiple layers with either S/MIME or PGP/MIME, for example, using the following structure:
たとえば、次の構造を使用して、S/MIMEまたはPGP/MIMEのいずれかを備えた複数の層で構成される暗号エンベロープを構築することが可能です。
A └┬╴application/pkcs7-mime; smime-type="enveloped-data"
B ╧ (decrypts to)
C └┬╴application/pkcs7-mime; smime-type="signed-data"
D ┴ (unwraps to)
E └─╴[protected part]
When handling such a message, the properties of the Cryptographic Envelope are derived from the series A and C.
そのようなメッセージを処理するとき、暗号封筒のプロパティは、シリーズAとCから派生しています。
As noted in Section 4.4.1, PGP/MIME applications also have a simpler MIME construction available with the same cryptographic properties.
セクション4.4.1で述べたように、PGP/MIMEアプリケーションには、同じ暗号化特性を備えたよりシンプルなMIME構造も利用できます。
Due to confusion, malice, message forwarding, or well-intentioned tampering, a message may contain a Cryptographic Layer that is not part of the Cryptographic Envelope. Such a layer is an Errant Cryptographic Layer.
混乱、悪意、メッセージの転送、または意図的な改ざんのため、メッセージには暗号化エンベロープの一部ではない暗号化層が含まれる場合があります。このような層は、誤った暗号化層です。
An Errant Cryptographic Layer MUST NOT contribute to the message's overall cryptographic state.
誤った暗号化層は、メッセージの全体的な暗号化状態に寄与してはなりません。
Guidance for dealing with Errant Cryptographic Layers can be found in Section 6.2.
誤った暗号化層を扱うためのガイダンスは、セクション6.2に記載されています。
Some mailing list software will rewrap a well-formed signed message before resending to add a footer, resulting in the following structure seen by recipients of the email:
一部のメーリングリストソフトウェアは、フッターを追加するために整理された署名付きメッセージを書き直します。
H └┬╴multipart/mixed
I ├┬╴multipart/signed
J │├─╴text/plain
K │└─╴application/pgp-signature
L └─╴text/plain
In this message, L is the footer added by the mailing list. I is now an Errant Cryptographic Layer.
このメッセージでは、lはメーリングリストによって追加されたフッターです。私は今、誤った暗号化層です。
Note that this message has no Cryptographic Envelope at all.
このメッセージには暗号化封筒がまったくないことに注意してください。
It is NOT RECOMMENDED to produce email messages with this structure, because a legacy MUA may present the data in part L as though it were part of J, though they have different cryptographic properties. In particular, if the user believes that the entire message is signed but cannot distinguish L from J, then the author of L can effectively tamper with content of the signed message, breaking the user's expectation of integrity and authenticity.
レガシーMUAは、異なる暗号プロパティを持っていますが、まるでJの一部であるかのようにレガシーMUAがパートLのデータを提示する可能性があるため、この構造で電子メールメッセージを作成することはお勧めしません。特に、ユーザーがメッセージ全体が署名されているがLとjを区別できないと考えている場合、Lの著者は署名されたメッセージのコンテンツを効果的に改ざんし、ユーザーの整合性と信頼性に対する期待を壊すことができます。
See also Section 6.2.1.1 for guidance on how a rendering MUA might deal with this common pattern.
レンダリングMUAがこの共通のパターンにどのように対処するかについてのガイダンスについては、セクション6.2.1.1も参照してください。
Consider a message with the following overcomplicated structure:
次の複雑な構造を持つメッセージを検討してください。
M └┬╴multipart/encrypted
N ├─╴application/pgp-encrypted
O └┬╴application/octet-stream
P ╧ (decrypts to)
Q └┬╴multipart/signed
R ├┬╴multipart/mixed
S │├┬╴multipart/signed
T ││├─╴text/plain
U ││└─╴application/pgp-signature
V │└─╴text/plain
W └─╴application/pgp-signature
The three Cryptographic Layers in such a message are rooted in parts M, Q, and S. But the Cryptographic Envelope of the message consists only of the properties derived from the series M and Q. The Cryptographic Payload of the message is part R. Part S is an Errant Cryptographic Layer.
このようなメッセージの3つの暗号化層は、パートM、Q、およびSに根ざしていますが、メッセージの暗号化エンベロープは、シリーズMとQから派生したプロパティのみになります。メッセージの暗号化ペイロードはパートRです。パートSは誤った暗号化層です。
Note that this message has both a Cryptographic Envelope _and_ an Errant Cryptographic Layer.
このメッセージには、暗号化エンベロープ_and_の両方が誤った暗号化層の両方を備えていることに注意してください。
It is NOT RECOMMENDED to generate messages with such complicated structures. Even if a receiving MUA can parse this structure properly, it is nearly impossible to render in a way that the user can reason about the cryptographic properties of part T compared to part V.
このような複雑な構造でメッセージを生成することはお勧めしません。受信MUAがこの構造を適切に解析できる場合でも、パートVと比較してパートTの暗号化特性についてユーザーが推論できる方法でレンダリングすることはほぼ不可能です。
The cryptographic status of an email message with end-to-end cryptographic protections is known as the Cryptographic Summary. A reasonable, simple Cryptographic Summary is derived from the aggregate properties of the layers in the Cryptographic Envelope. This is a conceptual tool and a feature that an MUA can use to guide behavior and user experience, but it is not necessarily always directly exposed in any given user interface. See Section 6.1 for guidance and considerations about rendering the Cryptographic Summary to the user.
エンドツーエンドの暗号化保護を備えた電子メールメッセージの暗号化ステータスは、暗号化の概要として知られています。合理的でシンプルな暗号化の要約は、暗号化エンベロープ内のレイヤーの集計特性から導き出されます。これは概念的なツールであり、MUAが動作とユーザーエクスペリエンスをガイドするために使用できる機能ですが、必ずしも特定のユーザーインターフェイスで常に直接露出しているわけではありません。暗号化の概要をユーザーにレンダリングすることに関するガイダンスと考慮事項については、セクション6.1を参照してください。
This section describes the ideal composition of an email message with end-to-end cryptographic protection. A message composed with this form is most likely to achieve its end-to-end security goals.
このセクションでは、エンドツーエンドの暗号化保護を備えた電子メールメッセージの理想的な構成について説明します。このフォームで構成されるメッセージは、エンドツーエンドのセキュリティ目標を達成する可能性が最も高くなります。
This section describes the steps that an MUA should use to compose a cryptographically protected message, such that it has a proper Cryptographic Envelope and Payload.
このセクションでは、MUAが暗号化された封筒とペイロードを備えた暗号化されたメッセージを作成するために使用する手順について説明します。
The inputs to the algorithm are:
アルゴリズムへの入力は次のとおりです。
origbody:
Origbody：
The unprotected message body as a well-formed MIME tree (possibly just a single MIME leaf part). As a well-formed MIME tree, origbody already has Structural Header Fields present (see Section 1.1.1).
保護されていないメッセージ本文は、よく形成されたmimeの木として（おそらく単一のmime葉の部分）。よく形成されたmimeの木として、Origbodyにはすでに構造ヘッダーフィールドが存在しています（セクション1.1.1を参照）。
origheaders:
origheaders：
The intended Non-Structural Header Fields for the message, represented here as a list of (h,v) pairs, where h is a header field name and v is the associated value.
メッセージの意図された非構造ヘッダーフィールドは、ここでは（h、v）ペアのリストとして表されます。ここで、hはヘッダーフィールド名で、vは関連する値です。
crypto:
暗号：
The series of cryptographic protections to apply (for example, "sign with the secret key corresponding to X.509 certificate X, then encrypt to X.509 certificates X and Y"). This is a routine that accepts a MIME tree as input (the Cryptographic Payload), wraps the input in the appropriate Cryptographic Envelope, and returns the resultant MIME tree as output.
適用する一連の暗号化保護（たとえば、「x.509証明書xに対応するシークレットキーで署名し、x.509証明書xおよびyに暗号化する」）。これは、MIMEツリーを入力（暗号化ペイロード）として受け入れ、入力を適切な暗号エンベロープにラップし、結果のMIMEツリーを出力として返すルーチンです。
The algorithm returns a MIME object that is ready to be injected into the mail system:
アルゴリズムは、メールシステムに注入する準備ができているMIMEオブジェクトを返します。
1. Apply crypto to MIME part origbody, producing MIME tree output.
1. CryptoをMime Part Origdodyに適用して、Mime Tree Outputを生成します。
2. For each header field name and value (h,v) in origheaders:
2. origheadersのヘッダーのフィールド名と値（h、v）について：
a. Add header field h to output with value v.
a. ヘッダーフィールドHを値Vで出力に追加します。
3. Return output.
3. 返品出力。
This is the classic algorithm. It only protects the Structural Header Fields of the message body and leaves Non-Structural (including User-Facing) Header Fields unprotected.
これは古典的なアルゴリズムです。メッセージ本文の構造ヘッダーフィールドのみを保護し、保護されていない非構造（ユーザー向け）ヘッダーフィールドを残します。
Therefore, a conformant MUA MUST implement Header Protection as described in [RFC9788] (see Section 9.3).
したがって、[RFC9788]に記載されているように、適合MUAはヘッダー保護を実装する必要があります（セクション9.3を参照）。
An email message that is both signed and encrypted is signed _inside_ the encryption and not the other way around. For example, when crafting a signed-and-encrypted message using a simple Cryptographic Envelope of a single layer (Section 4.4.1) with PGP/MIME, the OpenPGP Encrypted Message object should contain an OpenPGP Signed Message. Likewise, when using a multilayer Cryptographic Envelope (Section 4.4.2), the outer layer should be an encryption layer and the inner layer should be a signing layer.
署名されて暗号化された電子メールメッセージは、暗号化の_inside_であり、その逆ではありません。たとえば、PGP/MIMEを使用した単一層（セクション4.4.1）の単純な暗号エンベロープを使用して、署名付きおよび暗号化されたメッセージを作成する場合、OpenPGP暗号化されたメッセージオブジェクトには、OpenPGP署名されたメッセージを含める必要があります。同様に、多層暗号エンベロープ（セクション4.4.2）を使用する場合、外側の層は暗号化層である必要があり、内側の層は署名層である必要があります。
Putting the signature inside the encryption has two advantages:
暗号化の中に署名を置くことには、次の2つの利点があります。
* The details of the signature remain confidential, visible only to the parties capable of decryption.
* 署名の詳細は機密のままで、復号化が可能な当事者にのみ表示されます。
* Any mail transport agent that modifies the message is unlikely to be able to accidentally break the signature.
* メッセージを変更する郵便輸送エージェントは、署名を誤って破ることができる可能性は低いです。
A conformant MUA MUST NOT generate an encrypted and signed message where the only signature is outside the encryption.
コンフォーマントMUAは、暗号化の外側にある唯一の署名がある暗号化された署名メッセージを生成してはなりません。
When generating an email, there are four options for applying end-to-end cryptographic protections:
メールを生成するとき、エンドツーエンドの暗号化保護を適用するための4つのオプションがあります。
* Unprotected: In some cases, offering any end-to-end cryptographic protection is harmful: It may confuse the recipient and offer no benefit.
* 保護されていない：場合によっては、エンドツーエンドの暗号化保護を提供することは有害です。受信者を混乱させ、利益を提供しない場合があります。
* Signed-only: In other cases, signing a message is useful (authenticity and integrity are desirable), but encryption is either impossible (for example, if the composer does not know how to encrypt to all recipients) or meaningless (for example, an email message to a mailing list that is intended to be published to a public archive).
* 署名のみ：他のケースでは、メッセージに署名することが有用です（信頼性と整合性が望ましい）が、暗号化は不可能です（たとえば、作曲家がすべての受信者に暗号化する方法がわからない場合）または無意味（たとえば、公開されたアーカイブに公開されることを目的としたメーリングリストへの電子メールメッセージ）。
* Signed-and-encrypted: In other cases, full end-to-end confidentiality, authenticity, and integrity are desirable.
* 署名と暗号化：他の場合、完全なエンドツーエンドの機密性、信頼性、および整合性が望ましいです。
* Encrypted-only: There is no common use case for generating an email message with end-to-end confidentiality but without authenticity or integrity.
* 暗号化のみ：エンドツーエンドの機密性を備えた電子メールメッセージを生成するための一般的なユースケースはありませんが、信頼性や整合性はありません。
- Additionally, some encryption schemes are malleable. This allows an attacker to tamper with the plaintext by modifying the ciphertext (i.e., without decrypting it). One way to prevent this is to authenticate the ciphertext, e.g., using signatures, Message Authentication Codes (MACs), or Authenticated Encryption with Associated Data (AEAD) schemes. See the Cipher Block Chaining (CBC) / Cipher FeedBack (CFB) gadget attack in [EFAIL].
- さらに、一部の暗号化スキームは順応性があります。これにより、攻撃者は暗号文を変更することにより（つまり、復号化することなく）、プレーンテキストを改ざんすることができます。これを防ぐ方法の1つは、署名、メッセージ認証コード（Mac）、または関連するデータ（AEAD）スキームを使用した認証された暗号を使用して、暗号文を認証することです。[EFAIL]の暗号ブロックチェーン（CBC） /暗号フィードバック（CFB）ガジェット攻撃を参照してください。
A conformant MUA should keep its message composition interface simple. When presenting the user with a choice of cryptographic protection, it MUST offer no more than three choices:
コンフォーマントMUAは、メッセージ構成インターフェイスをシンプルに保つ必要があります。ユーザーに暗号化の保護を選択する場合、3つ以下の選択肢を提供する必要があります。
1. No end-to-end cryptographic protection
1. エンドツーエンドの暗号化保護はありません
2. Verified (signed only)
2. 検証（署名のみ）
3. Confidential (signed and encrypted)
3. Confidential（署名と暗号化）
Note that these choices correspond to the simplified mental model in Section 3.1.
これらの選択は、セクション3.1の単純化されたメンタルモデルに対応していることに注意してください。
A common anti-pattern among legacy MUAs is offering two boolean choices: one to toggle signing and another to toggle encryption. This creates usability hurdles:
レガシーMUASの間で一般的なアンチパターンは、2つのブールの選択肢を提供しています。1つは署名を切り替える、もう1つは暗号化を切り替えるためです。これにより、ユーザビリティのハードルが作成されます。
* A user who wants to compose a signed-and-encrypted message will have to click two buttons instead of one.
* 署名付きと暗号化されたメッセージを作成したいユーザーは、1つではなく2つのボタンをクリックする必要があります。
* A user who clicks "Encrypt" but neglects to click "Signed" may not understand that they are creating a message that cannot be authenticated by the recipient.
* 「暗号化」をクリックしているが、「署名された」をクリックすることを怠るユーザーは、受信者が認証できないメッセージを作成していることを理解していない場合があります。
When replying to a message, most MUAs compose an initial draft of the reply that contains quoted text from the original message. A responsible MUA will take precautions to avoid leaking the cleartext of an encrypted message in such a reply.
メッセージに返信するとき、ほとんどのMUASは、元のメッセージから引用されたテキストを含む返信の初期ドラフトを作成します。責任あるMUAは、そのような返信で暗号化されたメッセージのクリアテキストを漏らすことを避けるために予防策を講じます。
If the original message was end-to-end encrypted, the replying MUA MUST either:
元のメッセージがエンドツーエンドの暗号化されている場合、応答するMUAは次のとおりです。
* compose the reply with end-to-end encryption or
* エンドツーエンドの暗号化で返信を作成します
* avoid including quoted text from the original message.
* 元のメッセージから引用されたテキストを含めることは避けてください。
In general, MUAs SHOULD prefer the first option: to compose an encrypted reply. This is what users expect.
一般に、MUAは最初のオプションを好む必要があります。暗号化された返信を作成します。これはユーザーが期待するものです。
However, in some circumstances, the replying MUA cannot compose an encrypted reply. For example, the MUA might not have a valid, unexpired, and encryption-capable certificate for all recipients. This can also happen during composition when a user adds a new recipient into the reply or manually toggles the cryptographic protections to remove encryption.
ただし、状況によっては、返信MUAは暗号化された返信を作成できません。たとえば、MUAには、すべての受信者に対して有効な、期限切れ、暗号化対応証明書がない場合があります。これは、ユーザーが新しい受信者を返信に追加するか、暗号化を削除するために暗号化保護を手動で切り替えるときに、構成中にも発生する可能性があります。
In this circumstance, the composing MUA SHOULD strip the quoted text from the original message, unless the user indicates that they are deliberately including previously confidential content in a non-confidential message.
この状況では、構成MUAは、ユーザーが意図的に以前の機密コンテンツを非自信のメッセージに含めていることを示していない限り、元のメッセージから引用されたテキストを剥奪する必要があります。
Note additional nuance about replies to malformed messages that contain encryption in Section 6.2.2.1.
セクション6.2.2.1の暗号化を含む奇形のメッセージに対する返信に関する追加のニュアンスに注意してください。
Despite the best efforts of well-intentioned composers to create email messages with well-formed, end-to-end cryptographic protection, rendering MUAs will inevitably encounter some messages with malformed end-to-end cryptographic protection.
裕福なエンドツーエンドの暗号保護を備えた電子メールメッセージを作成するための善意の作曲家の最善の努力にもかかわらず、MUAのレンダリングは、不正なエンドツーエンドの暗号化保護を備えたいくつかのメッセージに必然的に遭遇します。
This section offers guidance on dealing with both well-formed and malformed messages containing Cryptographic Layers.
このセクションでは、暗号化層を含む整形式メッセージと奇形の両方のメッセージを扱うことに関するガイダンスを提供します。
A message is well-formed when it has a Cryptographic Envelope, a Cryptographic Payload, and no Errant Cryptographic Layers. Rendering a well-formed message is straightforward.
メッセージは、暗号化エンベロープ、暗号化のペイロード、および誤った暗号化層がない場合、適切に形成されます。よく形成されたメッセージをレンダリングするのは簡単です。
The rendering MUA evaluates and assembles the cryptographic properties of the Cryptographic Envelope into a Cryptographic Summary and displays that status to the user in a secure and strictly controlled part of the UI. In particular, the part of the UI used to render the Cryptographic Summary of the message MUST NOT be spoofable, modifiable, or otherwise controllable by the rendered message itself. By analogy, consider the "lock" icon in the address bar of the web browser: Regardless of the content of the webpage, the lock icon will only be displayed when the transport to the web server is adequately secured.
レンダリングMUAは、暗号封筒の暗号化特性を暗号化の要約に評価および組み立て、UIの安全で厳密に制御された部分でユーザーにそのステータスを表示します。特に、メッセージの暗号化の要約をレンダリングするために使用されるUIの一部は、レンダリングされたメッセージ自体によってスプーフィング可能、変更可能、またはその他の方法で制御可能であってはなりません。アナロジーでは、Webブラウザのアドレスバーの「ロック」アイコンを検討します。Webページのコンテンツに関係なく、ロックアイコンはWebサーバーへのトランスポートが適切に保護されている場合にのみ表示されます。
Aside from this Cryptographic Summary, the message itself MUST be rendered as though the Cryptographic Payload is the body of the message. The Cryptographic Layers themselves SHOULD NOT be rendered as distinct objects unless the MUA is providing the user with debugging information.
この暗号化の要約は別として、メッセージ自体は、暗号化のペイロードがメッセージの本文であるかのようにレンダリングする必要があります。暗号化層自体は、MUAがユーザーにデバッグ情報を提供していない限り、異なるオブジェクトとしてレンダリングされるべきではありません。
If an incoming message has any Errant Cryptographic Layers, a conformant interpreting MUA MUST ignore those layers when rendering the Cryptographic Summary of the message to the user.
着信メッセージに誤った暗号化レイヤーがある場合、メッセージの暗号化の要約をユーザーにレンダリングする際に、MUAをコンフォーマント解釈する必要があります。
When rendering a message with an Errant Cryptographic Layer that provides authenticity and integrity (via signatures), the message should be rendered by replacing the Cryptographic Layer with the part it encloses.
（署名を介して）真正性と整合性を提供する誤った暗号化層でメッセージをレンダリングする場合、暗号化層を囲む部分に置き換えることにより、メッセージをレンダリングする必要があります。
For example, a message with this structure:
たとえば、この構造のメッセージ：
A └┬╴multipart/mixed
B ├╴text/plain
C ├┬╴multipart/signed
D │├─╴image/jpeg
E │└─╴application/pgp-signature
F └─╴text/plain
should be rendered identically to this:
これと同じようにレンダリングする必要があります。
A └┬╴multipart/mixed
B ├─╴text/plain
D ├─╴image/jpeg
F └─╴text/plain
In such a situation, a conformant MUA MUST NOT indicate in the Cryptographic Summary that the message is signed. It MUST indicate that the message is Unprotected.
このような状況では、コンフォーマントMUAは、メッセージが署名されていることを暗号化の要約に示してはなりません。メッセージが保護されていないことを示す必要があります。
The use case described in Section 4.5.1 is common enough in some contexts that a conformant MUA MAY decide to handle it as a special exception.
セクション4.5.1で説明されているユースケースは、一部のコンテキストで十分に一般的であるため、コンフォーマントMUAが特別な例外として処理することを決定する場合があります。
If the MUA determines that the message comes from a mailing list (for example, it has a List-ID header field) and it has a structure that appends a footer to a signing-only Cryptographic Layer with a valid signature, such as:
MUAがメッセージがメーリングリスト（たとえば、List-IDヘッダーフィールドがある）からのものであると判断し、次のような有効な署名を持つ署名専用の暗号化レイヤーにフッターを追加する構造がある場合
H └┬╴multipart/mixed
I ├┬╴multipart/signed
J │├─╴[protected part, may be arbitrary MIME subtree]
K │└─╴application/{pgp,pkcs7}-signature
L └─╴[footer, typically text/plain]
or:
or:
H └┬╴multipart/mixed
I ├┬╴application/pkcs7-mime; smime-type="signed-data"
│┴ (unwraps to)
J │└─╴[protected part, may be an arbitrary MIME subtree]
L └─╴[footer, typically text/plain]
then the MUA MAY indicate to the user that this is a Verified message that has been wrapped by the mailing list.
次に、MUAは、これがメーリングリストに包まれている検証済みのメッセージであることをユーザーに示す場合があります。
In this case, the MUA MUST distinguish the footer (part L) from the protected part (part J) when rendering any information about the signature.
この場合、MUAは、署名に関する情報をレンダリングする際に、フッター（パートL）を保護された部品（パートJ）と区別する必要があります。
One way to do this is to offer the user two different views of the message: the "mailing list" view, which hides any positive Cryptographic Summary but shows the footer:
これを行う1つの方法は、ユーザーにメッセージの2つの異なるビューを提供することです。「メーリングリスト」ビューは、肯定的な暗号要約を隠しているがフッターを示しています。
Cryptographic Protections: Unprotected
H └┬╴multipart/mixed
J ├─╴[protected part, may be arbitrary MIME subtree]
L └─╴[footer, typically text/plain]
or the "sender's view", which shows the Cryptographic Summary as Verified but hides the footer:
または、「送信者のビュー」は、検証されたが、フッターを隠していると思われる暗号化の概要を示しています。
Cryptographic Protections: Verified [details from part I]
J └─╴[protected part, may be arbitrary MIME subtree]
An MUA may encounter a message with an Errant Cryptographic Layer that offers confidentiality (encryption), and the MUA is capable of decrypting it.
MUAは、機密性（暗号化）を提供する誤った暗号化層でメッセージに遭遇する可能性があり、MUAはそれを復号化することができます。
The user wants to be able to see the contents of any message that they have access to, so a conformant MUA in this situation SHOULD decrypt the part.
ユーザーは、アクセスできるメッセージの内容を表示できるようにしたいため、この状況での適合MUAは部品を解読する必要があります。
However, in this case, a conformant MUA MUST NOT indicate in the message's Cryptographic Summary that the message itself was encrypted. Such an indication could be taken to mean that other (non-encrypted) parts of the message arrived with cryptographic confidentiality.
ただし、この場合、メッセージの暗号化要約で、メッセージ自体が暗号化されたことを示すことはできません。このような兆候は、メッセージの他の（暗号化されていない）部分が暗号化の機密性を備えて到着したことを意味するように取られる可能性があります。
Furthermore, when decrypting an Errant Cryptographic Layer, the MUA MUST treat the decrypted cleartext as a distinct MIME subtree and it MUST NOT attempt to merge or splice it together with any other part of the message. This offers protection against the direct exfiltration (also known as EFAIL-DE) attacks described in [EFAIL] and so-called multipart/oracle attacks described in [ORACLE].
さらに、誤った暗号化層を復号化する場合、MUAは復号化されたクリアテキストを明確なMimeサブツリーとして扱う必要があり、メッセージの他の部分とマージまたはスプライスしようとしてはなりません。これにより、[eFail]およびいわゆるマルチパート/オラクル攻撃に記載されている直接的な剥離（EFAIL-DEとも呼ばれる）攻撃に対する保護が提供されます。
Note that there is an asymmetry here between rendering and replying to a message with an Errant Encryption Layer.
ここには、レンダリングと誤った暗号化レイヤーを使用したメッセージへの応答との間に非対称性があることに注意してください。
When rendering, the MUA does not indicate that the message was encrypted, even if some subpart of it was decrypted for rendering.
レンダリングの場合、MUAは、メッセージが暗号化されたことを示していません。
When composing a reply to a message that has any encryption layer, even an errant one, the reply message SHOULD be marked for encryption, unless quoted and attributed text is not included in the reply, as noted in Section 5.4.
暗号化レイヤーを誤ったレイヤーにしているメッセージへの返信を作成する場合、セクション5.4に記載されているように、引用と帰属テキストが返信に含まれていない場合を除き、暗号化のために応答メッセージをマークする必要があります。
When composing a reply to a message with an Errant Cryptographic Layer, a conformant MUA MUST NOT quote or attribute text derived from the decryption of any Errant Cryptographic Layer. This will typically mean either leaving the ciphertext itself in the generated reply message or simply not generating any quoted or attributed text at all. This offers protection against the reply-based attacks described in [REPLY].
誤った暗号化層を使用してメッセージへの返信を作成する場合、誤った暗号化層の復号化から導き出されたテキストを引用または属性にしてはなりません。これは通常、生成された返信メッセージに暗号文自体を離れるか、単に引用符または属性のあるテキストをまったく生成しないことを意味します。これは、[Reply]に記載されている返信ベースの攻撃に対する保護を提供します。
In all circumstances, if the reply message cannot be encrypted (or if the user elects to not encrypt the reply), the composed reply MUST NOT include any material from the decrypted subpart.
あらゆる状況で、返信メッセージを暗号化できない場合（または、ユーザーが返信を暗号化しないことを選択した場合）、構成された返信には、復号化されたサブパートからの資料を含めてはなりません。
In some cases, there may be a cryptographic signature or encryption that does not coincide with a MIME boundary. For example, so-called "PGP Inline" messages typically contain base64-encoded ("ASCII-armored", see Section 6 of [RFC9580]) ciphertext within the content of a MIME part.
場合によっては、mime境界と一致しない暗号化の署名または暗号化がある場合があります。たとえば、いわゆる「PGPインライン」メッセージには、通常、MIME部品のコンテンツ内の[RFC9580]のセクション6を参照してください。
When encountering cryptographic signatures in these positions, a conformant MUA MUST NOT attempt to validate any signature. It is challenging to communicate to the user exactly which part of such a message is covered by the signature, so it is better to leave the message marked as Unprotected. See [SPOOFING] for examples of spoofed message signatures that rely on permissive legacy clients that are willing to validate signatures in poorly structured messages.
これらの位置で暗号化の署名に遭遇した場合、適合MUAは署名を検証しようとしてはなりません。このようなメッセージのどの部分が署名によってカバーされているかをユーザーに正確に通信することは困難です。そのため、メッセージを保護されていないとマークされたままにしておくことをお勧めします。[スプーフィング]を参照してください。[スプーフィング]は、構造化されていないメッセージで署名を検証する意思のある寛容なレガシークライアントに依存しているスプーフィングされたメッセージ署名の例を参照してください。
When encountering what appears to be encrypted data not at a MIME boundary, a conformant MUA MAY fully decline to decrypt the data.
MIME境界ではない暗号化されたデータと思われるものに遭遇した場合、コンフォーマントMUAはデータを復号化するために完全に拒否される可能性があります。
During message rendering, if a conformant MUA attempts decryption of such a non-MIME encrypted section of an email, it MUST synthesize a separate MIME part to contain only the decrypted data and it MUST NOT attempt to merge or splice that part together with any other part of the message. Keeping such a section distinct and isolated from any other part of the message offers protection against the direct exfiltration attacks (also known as EFAIL-DE) described in [EFAIL].
メッセージのレンダリング中、コンフォーマントMUAが電子メールのそのような非mime暗号化されたセクションの復号化を試みた場合、復号化されたデータのみを含むように別のMIME部分を合成する必要があり、その部分をメッセージの他の部分とマージまたはスプライスしようとしてはなりません。このようなセクションをメッセージの他の部分から明確に隔離することは、[eFail]で説明されている直接的な剥離攻撃（EFAIL-DEとも呼ばれる）に対する保護を提供します。
When composing a reply to a message with such a non-MIME encrypted section, a conformant MUA MUST NOT decrypt any non-MIME encrypted section when generating quoted or attributed text, similar to the guidance in Section 6.2.2.1.
このような非mime暗号化されたセクションでメッセージへの返信を作成する場合、セクション6.2.2.1のガイダンスと同様に、引用符または属性テキストを生成したときに、コンフォーマンテマントMUAは、非mime暗号化されたセクションを復号化してはなりません。
This offers protection against the reply-based attacks described in [REPLY].
これは、[Reply]に記載されている返信ベースの攻撃に対する保護を提供します。
An incoming email message may include an attached forwarded message, typically as a MIME subpart with Content-Type: message/rfc822 [RFC5322] or Content-Type: message/global [RFC6532].
着信電子メールメッセージには、通常、コンテンツタイプのMIMEサブパートとして添付された転送メッセージが含まれる場合があります：メッセージ/RFC822 [RFC5322]またはコンテンツタイプ：メッセージ/グローバル[RFC6532]。
Regardless of the cryptographic protections and structure of the incoming message, the internal forwarded message may have its own Cryptographic Envelope.
着信メッセージの暗号化の保護と構造に関係なく、内部転送されたメッセージには独自の暗号エンベロープがある場合があります。
The Cryptographic Layers that are part of the Cryptographic Envelope of the forwarded message are Errant Cryptographic Layers with respect to the surrounding message -- they are layers that only apply to the forwarded message itself.
転送されたメッセージの暗号化封筒の一部である暗号化層は、周囲のメッセージに関して誤った暗号化層です。これらは、転送されたメッセージ自体にのみ適用されるレイヤーです。
A conformant rendering MUA MUST NOT conflate the cryptographic protections of the forwarded message with the cryptographic protections of the incoming message.
コンフォーマントレンダリングMUAは、転送されたメッセージの暗号化保護を、着信メッセージの暗号化保護と混同してはなりません。
A conformant rendering MUA MAY render a Cryptographic Summary of the protections afforded to the forwarded message by its own Cryptographic Envelope, as long as that rendering is unambiguously tied to the forwarded message itself and cannot be spoofed by either the enclosing message or the forwarded message.
コンフォーマントレンダリングMUAは、そのレンダリングが転送されたメッセージ自体に明確に結び付けられており、囲いのメッセージまたは転送されたメッセージのいずれかによってスプーフィングできない限り、独自の暗号化エンベロープによって転送されたメッセージに与えられた保護の暗号化の要約をレンダリングする可能性があります。
A cryptographic signature may fail in multiple ways. A conformant rendering MUA that discovers a failed signature treats the message as though the signature did not exist. This is similar to the standard guidance for failed DomainKeys Identified Mail (DKIM) signatures (see Section 6.1 of [RFC6376]).
暗号化の署名は、複数の方法で失敗する場合があります。失敗した署名を発見したコンフォーマントレンダリングMUAは、署名が存在しないかのようにメッセージを扱います。これは、失敗したドメインキー識別されたメール（DKIM）署名の標準ガイダンスに似ています（[RFC6376]のセクション6.1を参照）。
A conformant MUA MUST NOT render a message with a failed signature as more dangerous or more dubious than a comparable message without any signature at all. In both cases, the Cryptographic Summary should be Unprotected.
コンフォーマントMUAは、まったく署名なしで匹敵するメッセージよりも危険またはより疑わしいものとして失敗した署名を持つメッセージをレンダリングしてはなりません。どちらの場合も、暗号化の概要は保護されていません。
A conformant MUA that encounters a signed-and-encrypted message where the signature is invalid SHOULD treat the message the same way that it would treat a message that is encryption-only, unless the MUA is providing the user with debugging information.
署名が無効である署名と暗号化されたメッセージに遭遇するコンフォーマントMUAは、MUAがユーザーにデバッグ情報を提供しない限り、暗号化のみのメッセージを扱うのと同じようにメッセージを扱う必要があります。
These are some different ways that a signature may be invalid on a given message:
これらは、特定のメッセージで署名が無効になる可能性があるいくつかの異なる方法です。
* The signature is not cryptographically valid (the math fails).
* 署名は暗号化的に有効ではありません（数学は失敗します）。
* The signature relies on suspect cryptographic primitives (e.g., over a deprecated digest algorithm, or was made by a weak key, e.g., 1024-bit RSA); note that this requires the rendering MUA to have an explicit policy about what cryptographic primitives are acceptable.
* 署名は、疑わしい暗号化プリミティブに依存しています（たとえば、Digest Algorithmを非推奨、または弱いキー、たとえば1024ビットRSAによって作成されました）。これには、レンダリングMUAに、暗号化プリミティブが許容できるものに関する明示的なポリシーが必要であることに注意してください。
* The signature is made by a certificate that the rendering MUA does not have access to.
* 署名は、レンダリングMUAにアクセスできない証明書によって作成されます。
* The certificate used to verify the signature was revoked.
* 署名の確認に使用される証明書は取り消されました。
* The certificate used to verify the signature was expired at the time that the signature was made.
* 署名を確認するために使用される証明書は、署名が作成された時点で期限切れになっています。
* The certificate used to verify the signature does not correspond to the author of the message. (For X.509, there is no subjectAltName of type rfc822Name whose value matches an email address found in the From or Sender header field.)
* 署名を確認するために使用される証明書は、メッセージの著者に対応していません。（x.509の場合、fromまたは送信者ヘッダーフィールドにある電子メールアドレスと値と一致するタイプのrfc822nameのsubjectaltnameはありません。）
* The certificate used to verify the signature was not issued by an authority that the MUA user is willing to rely on for certifying the sender's email address, and the user has no other reasonable indication that the certificate belongs to the sender's email address.
* 署名を確認するために使用される証明書は、MUAユーザーが送信者のメールアドレスを証明するために頼る意思があるという当局によって発行されておらず、ユーザーは証明書が送信者のメールアドレスに属しているという他の合理的な兆候を持っていません。
* The signature indicates that it was made at a time much before or much after the date of the message itself.
* 署名は、メッセージ自体の日付からずっと前またはずっと後に作成されたことを示しています。
* The signature covers a message that depends on an external subresource that might change (see Section 9.9).
* 署名は、変更される可能性のある外部サブリソースに依存するメッセージをカバーします（セクション9.9を参照）。
A valid signature must pass all these tests, but of course, invalid signatures may be invalid in more than one of the ways listed above.
有効な署名はこれらすべてのテストに合格する必要がありますが、もちろん、上記の複数の方法で無効な署名が無効になる場合があります。
Sometimes, an MUA might encounter a message with a well-formed Cryptographic Envelope that uses a form of encryption with substantial known flaws. For example, a PGP/MIME message might use a Symmetrically Encrypted Data Packet, which is known to have malleable ciphertext (see Section 5.7 of [RFC9580]). As another example, an S/ MIME message may use an enveloped-data MIME part with a contentEncryptionAlgorithm of rc2-cbc with rc2ParameterVersion of 160, meaning a 40-bit key (see Section 5.2 of [RFC3370]), which is widely considered breakable via brute force with moderate hardware investment in 2024. As cryptanalysis and hardware capacities advance, an implementation may widen the scope of what encryption mechanisms are considered weak.
時々、MUAは、実質的な既知の欠陥を持つ形式の暗号化を使用する、よく形成された暗号化エンベロープでメッセージに遭遇する可能性があります。たとえば、PGP/MIMEメッセージは、対称的に暗号化されたデータパケットを使用する場合があります。これは、順応性のある暗号文を持つことが知られています（[RFC9580]のセクション5.7を参照）。別の例として、S/ MIMEメッセージは、160のRC2PARAMeterVersionを備えたRC2ParameterVerversionを備えたRC2ParametrycontaAlgorithmを備えた包括的なData Mimeパーツを使用する場合があります（[RFC3370]のセクション5.2を参照）。どの暗号化メカニズムが弱いと見なされるかの範囲。
A rendering MUA MUST warn the user that such a message has a known weakness. The rendering MUA MAY fully decline to decrypt such a message. If it decides to decrypt a message with a weak encryption layer, it MUST NOT indicate in the message's Cryptographic Summary that the message was encrypted, as the confidentiality of the message is suspect. This is similar to the approach taken in Section 6.2.2 for messages with an Errant Encryption Layer.
レンダリングMUAは、そのようなメッセージには既知の弱点があることをユーザーに警告する必要があります。レンダリングMUAは、そのようなメッセージを復号化することを完全に拒否する可能性があります。暗号化レイヤーが弱いメッセージを復号化することを決定した場合、メッセージの機密性が疑われるため、メッセージの暗号化の要約を暗号化されたことを示してはなりません。これは、誤った暗号化層を持つメッセージのセクション6.2.2で採用されたアプローチに似ています。
Like the Errant Encryption Layer situation, there is an asymmetry between rendering and replying to a message with weak encryption. The guidance in Section 6.2.2.1 should be followed when replying to a message with weak encryption as well.
誤った暗号化層の状況のように、暗号化が弱いメッセージに応答することと、レンダリングと応答の間に非対称性があります。暗号化が弱いメッセージにも返信するときは、セクション6.2.2.1のガイダンスに従う必要があります。
A rendering MUA MAY also treat historically archived messages with weak encryption differently than modern messages. For example, if an encryption algorithm was known to be weak in 2005, then a message that appears to have been encrypted with that algorithm in 1995 might be decrypted with a warning, as an archival service. But a message that appears to have been encrypted with that same weak algorithm in 2015 might be quarantined as a likely attack.
レンダリングMUAは、最新のメッセージとは異なる暗号化の歴史的にアーカイブされたメッセージを扱うこともできます。たとえば、2005年に暗号化アルゴリズムが弱いことがわかっている場合、1995年にそのアルゴリズムで暗号化されたと思われるメッセージは、アーカイブサービスとして警告で復号化される可能性があります。しかし、2015年に同じ弱いアルゴリズムで暗号化されたと思われるメッセージは、攻撃の可能性が隔離される可能性があります。
There are several possible ways to distinguish a historical message from a modern one, including:
歴史的なメッセージを現代のメッセージと区別する方法はいくつかあります。
* the message timestamp (e.g., the Date header field)
* メッセージタイムスタンプ（日付ヘッダーフィールドなど）
* the time the message was first observed on the network (e.g., delivery of a new message via IMAP from a mailbox that had recently checked)
* メッセージがネットワークで最初に観察された時（たとえば、最近チェックしたメールボックスからIMAPを介して新しいメッセージの配信）
* the timestamp in any signature observed in the message
* メッセージで観察されたあらゆる署名のタイムスタンプ
* the message structure (a message composed using protocol elements that were invented after the encryption algorithm was known as weak is more likely to be an attack than a legitimate archival message)
* メッセージ構造（暗号化アルゴリズムが弱いと知られている後に発明されたプロトコル要素を使用して構成されたメッセージは、正当なアーカイブメッセージよりも攻撃である可能性が高い）
When generating or rendering messages, it is useful to know what parts of the message are likely to be displayed and how. This section introduces some common terms that can be applied to parts within the Cryptographic Payload.
メッセージを生成またはレンダリングするとき、メッセージのどの部分が表示される可能性があるか、どのように表示されるかを知ることが有用です。このセクションでは、暗号化ペイロード内の部品に適用できるいくつかの一般的な用語を紹介します。
When an email message is composed or rendered to the user, there is typically one main view that presents a (mostly textual) part of the message.
電子メールメッセージが作成またはレンダリングされた場合、メッセージの（ほとんどテキストの）部分を提示する主要なビューが通常1つあります。
While the message itself may be constructed of several distinct MIME parts in a tree, the part that is rendered to the user is the "Main Body Part".
メッセージ自体はツリー内のいくつかの異なるmimeパーツで構成されている場合がありますが、ユーザーにレンダリングされる部分は「メインの部分」です。
When rendering a message, one of the primary jobs of the rendering MUA is identifying which part (or parts) is the Main Body Part. Typically, this is found by traversing the MIME tree of the message looking for a leaf node that has text (e.g., text/plain or text/html) as a primary content type and is not Content-Disposition: attachment.
メッセージをレンダリングするとき、レンダリングMUAの主要な仕事の1つは、どの部分（または部分）が本体の部分であるかを識別することです。通常、これは、主要なコンテンツタイプとしてテキスト（テキスト/プレーンまたはテキスト/HTMLなど）を持つ葉のノードを探してメッセージのマイムツリーを横断することによって発見されます。
MIME tree traversal follows the first child of every multipart node, with the exception of multipart/alternative. When traversing a multipart/alternative node, all children should be scanned, with preference given to the last child node with a MIME type that the MUA is capable of rendering directly.
Mime Tree Traversalは、MultiPart/Alternativeを除き、すべてのマルチパートノードの最初の子に続きます。マルチパート/代替ノードを横断するときは、すべての子供をスキャンする必要があり、MUAが直接レンダリングできるMIMEタイプで最後の子供ノードを好み、優先します。
An MUA MAY let the user select a preferred MIME type for rendering within multipart/alternative instead of the last renderable child. For example, a user may explicitly prefer a text/plain alternative part over text/html. Note that due to uncertainty about the capabilities and configuration of the rendering MUA, a conformant composing MUA should consider that multiple parts might be rendered as the Main Body Part when the message is ultimately viewed. In particular, the composing MUA should ensure that any part likely to be viewed as the Main Body Part has the same semantic content as any other such part.
MUAは、最後のレンダリング可能な子供ではなく、マルチパート/代替でレンダリングするために、ユーザーが優先マイムタイプを選択できるようにすることができます。たとえば、ユーザーは、テキスト/HTMLよりもテキスト/プレーンの代替部分を明示的に好む場合があります。レンダリングMUAの機能と構成に関する不確実性のため、MUAをコンポルティングするコンフォーマントな構成MUAは、メッセージが最終的に表示されたときに、複数の部分がメインの部分としてレンダリングされる可能性があることを考慮すべきであることに注意してください。特に、構成MUAは、本体の部分と見なされる可能性のある部分が他のそのような部分と同じセマンティックコンテンツを持っていることを保証する必要があります。
When composing a message, an originating MUA operating on behalf of an active user can identify which part (or parts) are the "main" parts: These are the parts the MUA generates from the user's editor. Tooling that automatically generates email messages should also have a reasonable estimate of which part (or parts) are the "main" parts, as they can be programmatically identified by the message author.
メッセージを作成する場合、アクティブなユーザーに代わって動作する起源のMUAは、どのパーツ（または部品）が「メイン」パーツであるかを識別できます。これらは、ユーザーのエディターからMUAが生成するパーツです。電子メールメッセージを自動的に生成するツールには、メッセージ作成者がプログラム的に識別できるように、「メイン」パーツであるパーツ（またはパーツ）が「メイン」パーツであるかどうかを合理的に推定する必要があります。
For a filtering program that attempts to transform an outbound message without any special knowledge about which parts are the Main Body Parts, it can identify the likely parts by following the same routine as a rendering MUA.
どの部分が本体の部分であるかについての特別な知識なしにアウトバウンドメッセージを変換しようとするフィルタリングプログラムの場合、レンダリングMUAと同じルーチンに従うことで、可能性のある部分を識別できます。
A message may contain one or more separated MIME parts that are intended for download or extraction. Such a part is commonly called an "attachment" and is commonly identified by having Content-Disposition: attachment.
メッセージには、ダウンロードまたは抽出を目的とした1つ以上の分離されたMIMEパーツが含まれている場合があります。このような部分は一般に「添付ファイル」と呼ばれ、コンテンツ拡張：添付ファイルを持つことによって一般的に識別されます。
An MUA MAY identify a subpart as an attachment or permit extraction of a subpart even when the subpart does not have Content-Disposition: attachment.
MUAは、サブパートにサブパートにコンテンツディスポジション：アタッチメントがない場合でも、サブパートをアタッチメントとして識別するか、サブパートの抽出を許可する場合があります。
When generating a message with end-to-end cryptographic protection, any attachment MUST be included within the Cryptographic Payload. If an attachment is found outside the Cryptographic Payload, then the message is not well-formed (see Section 6.1) and will not be handled by other MUAs as intended.
エンドツーエンドの暗号化保護を備えたメッセージを生成する場合、添付ファイルは暗号化ペイロードに含める必要があります。添付ファイルが暗号化のペイロードの外側にある場合、メッセージは順調に形成されておらず（セクション6.1を参照）、意図したとおりに他のMUAによって処理されません。
Some MUAs have tried to compose messages where each attachment is placed in its own Cryptographic Envelope. Such a message is problematic for several reasons:
一部のMUAは、各添付ファイルが独自の暗号エンベロープに配置されているメッセージを作成しようとしました。このようなメッセージは、いくつかの理由で問題があります。
* The attachments can be stripped, replaced, or reordered without breaking any cryptographic integrity mechanism.
* 添付ファイルは、暗号化の整合性メカニズムを破ることなく、剥がしたり、交換したり、並べ替えたりすることができます。
* The resulting message may have a mix of cryptographic statuses (e.g., if a signature on one part fails but another succeeds or if one part is encrypted and another is not). This mix of statuses is difficult to represent to the user in a comprehensible way.
* 結果のメッセージには、暗号化ステータスが混在する場合があります（たとえば、ある部分の署名が失敗したが別の部分が成功した場合、または1つの部分が暗号化され、別の部分がそうでない場合）。このステータスの組み合わせは、理解できる方法でユーザーに表現することが困難です。
* The divisions between the different attachments are visible to operators of any mail transport agent (MTA) that handles the message, potentially resulting in a metadata leak. For example, the MTA operator may learn the number of attachments and the size of each attachment.
* 異なる添付ファイル間の区分は、メッセージを処理する任意の郵便輸送エージェント（MTA）の演算子に表示され、メタデータが漏れる可能性があります。たとえば、MTAオペレーターは、添付ファイルの数と各添付ファイルのサイズを学習できます。
These messages are unlikely to be usefully interoperable without additional standardization work (see Appendix A.12).
これらのメッセージは、追加の標準化作業なしに有用に相互運用可能である可能性は低い（付録A.12を参照）。
Consider a common message with the following MIME structure:
次のmime構造を持つ一般的なメッセージを検討してください。
M └┬╴application/pkcs7-mime
╧ (decrypts to)
N └┬╴application/pkcs7-mime
┴ (unwraps to)
O └┬╴multipart/mixed
P ├┬╴multipart/alternative
Q │├─╴text/plain
R │└─╴text/html
S └─╴image/png
Parts M and N comprise the Cryptographic Envelope.
パートMとNは、暗号化エンベロープを含みます。
Parts Q and R are both Main Body Parts.
パーツQとRはどちらも本体の部分です。
If part S is Content-Disposition: attachment, then it is an attachment. If part S has no Content-Disposition header field, it is potentially ambiguous whether it is an attachment or not. If the composer prefers a specific behavior, it should explicitly set the Content-Disposition header field on part S to either inline or attachment as guidance to the rendering MUA.
パーツSがコンテンツ拡張：添付ファイルの場合、それは添付ファイルです。パートSにコンテンツディスポジションヘッダーフィールドがない場合、それが添付ファイルであるかどうかは潜在的に曖昧です。作曲家が特定の動作を好む場合、レンダリングMUAへのガイダンスとして、パートSのコンテンツディスポジションヘッダーフィールドをインラインまたはアタッチメントのいずれかに明示的に設定する必要があります。
Consider also this alternate structure:
この代替構造も考えてみましょう。
M └┬╴application/pkcs7-mime
╧ (decrypts to)
N └┬╴application/pkcs7-mime
┴ (unwraps to)
O └┬╴multipart/alternative
P ├─╴text/plain
Q └┬╴multipart/related
R ├─╴text/html
S └─╴image/png
In this case, parts M and N still comprise the Cryptographic Envelope.
この場合、パートMとNは依然として暗号化エンベロープを構成します。
Parts P and R (the first two leaf nodes within each subtree of part O) are the Main Body Parts.
パーツPとR（パートoの各サブツリー内の最初の2つの葉のノード）は、本体の部分です。
Part S is more likely not to be an attachment, as the subtree layout suggests that it is only relevant for the HTML version of the message. For example, it might be rendered as an image within the HTML alternative.
サブツリーレイアウトは、メッセージのHTMLバージョンにのみ関連していることを示唆しているため、パートSは添付ファイルではない可能性が高くなります。たとえば、HTMLの代替案内の画像としてレンダリングされる場合があります。
A cryptographically capable MUA typically maintains knowledge about certificates for the user's own account(s), as well as certificates for the peers that it communicates with.
暗号化できるMUAは通常、ユーザー自身のアカウントの証明書に関する知識と、通信するピアの証明書を維持します。
Most certificates that a cryptographically capable MUA will use will be certificates belonging to the parties that the user communicates with through the MUA. This section discusses how to manage the certificates that belong to such a peer.
暗号化できるMUAが使用するほとんどの証明書は、ユーザーがMUAを介して通信する当事者に属する証明書です。このセクションでは、そのようなピアに属する証明書を管理する方法について説明します。
The MUA will need to be able to discover X.509 certificates for each peer, cache them, and select among them when composing an encrypted message. Detailed guidance about how to do this is beyond the scope of this document, but future revisions may bring it into scope (see Appendix A.3).
MUAは、ピアごとにX.509証明書を発見し、それらをキャッシュし、暗号化されたメッセージを作成するときにそれらを選択できる必要があります。これを行う方法に関する詳細なガイダンスは、このドキュメントの範囲を超えていますが、将来の改訂により範囲に導かれる可能性があります（付録A.3を参照）。
When composing an encrypted message, the MUA needs to select an encryption-capable certificate for each recipient.
暗号化されたメッセージを作成する場合、MUAは各受信者に対して暗号化対応証明書を選択する必要があります。
To select such a certificate for a given destination email address, the MUA should look through all of its known certificates and verify that _all_ of the conditions below are met:
特定の宛先メールアドレスのこのような証明書を選択するには、MUAは既知のすべての証明書を調べ、以下の条件の_all_が満たされていることを確認する必要があります。
* The certificate must be valid, not expired or revoked.
* 証明書は有効であり、期限切れまたは取り消されたものではありません。
* It must have a subjectAltName of type rfc822Name (for all ASCII email addresses) or SmtpUTF8Mailbox (for Internationalized Email Addresses) whose contents match the destination email address. In particular, for rfc822Name, the local-part of the two addresses should be an exact bytewise match, and the domain parts of the two addresses should be matched by ensuring label equivalence across the full domain name, as described in Section 2.3.2.4 of [RFC5890]. Comparison with SmtpUTF8Mailbox is specified in Section 5 of [RFC9598].
* 宛先の電子メールアドレスと一致するコンテンツを持つrfc822nameのタイプrfc822name（すべてのASCIIメールアドレスに対して）またはsmtputf8mailbox（国際化されたメールアドレス用）のsumberaltnameが必要です。特に、RFC822NAMEの場合、2つのアドレスのローカルパートは正確なバイトワイズマッチである必要があり、2つのアドレスのドメイン部分は、[RFC5890]のセクション2.3.2.4で説明されているように、ドメイン名全体にラベルの等価性を確保することによって一致する必要があります。SmtputF8Mailboxとの比較は、[RFC9598]のセクション5で指定されています。
* The algorithm OID in the certificate's SubjectPublicKeyInfo (SPKI) is known to the MUA and capable of encryption. Examples include:
* 証明書のsubjectpublickeyinfo（SPKI）のアルゴリズムoidは、MUAに知られており、暗号化が可能です。例は次のとおりです。
- rsaEncryption (OID 1.2.840.113549.1.1.1), with the keyUsage (OID 2.5.29.15) extension present and the "key encipherment" bit (value 32) set.
- rsaencryption（oid 1.2.840.113549.1.1.1.1）、keyusage（oid 2.5.29.15）拡張が存在し、「キーエンシファメント」ビット（値32）セットが設定されています。
- curveX25519 (OID 1.3.101.110), with the keyUsage extension present and the "key agreement" bit (value 8) set.
- Curvex25519（OID 1.3.101.110）、keyuSage拡張が存在し、「キー契約」ビット（値8）が設定されています。
* If extendedKeyUsage (OID 2.5.29.37) is present, it contains at least one of the following OIDs: email protection (OID 1.3.6.1.5.5.7.3.4), anyExtendedKeyUsage (OID 2.5.29.37.0).
* ExtendedKeyUsage（OID 2.5.29.37）が存在する場合、次のOIDの少なくとも1つが含まれています。電子メール保護（OID 1.3.6.1.1.5.5.7.3.4）、AnyextededKeyUsage（OID 2.5.29.37.0）。
A conformant MUA may include more considerations when selecting a peer certificate as well; see Appendix A.3.4 for examples.
コンフォーマントMUAには、ピア証明書を選択する際にも、より多くの考慮事項が含まれる場合があります。例については、付録A.3.4を参照してください。
The MUA also needs to know about one or more certificates associated with the user's email account. It is typically expected to have access to the secret key material associated with the public keys in those certificates.
MUAは、ユーザーのメールアカウントに関連付けられている1つ以上の証明書についても知る必要があります。通常、これらの証明書のパブリックキーに関連する秘密の鍵資料にアクセスできることが期待されています。
While some basic guidance is offered here, it is beyond the scope of this document to describe all possible relevant guidance for local certificate and key material handling. See Appendix A.4 for suggestions of guidance that a future version might bring into scope.
ここではいくつかの基本的なガイダンスが提供されていますが、ローカル証明書と主要なマテリアルハンドリングに関するすべての可能な関連するガイダンスを説明するのは、このドキュメントの範囲を超えています。将来のバージョンが範囲に導入される可能性のあるガイダンスの提案については、付録A.4を参照してください。
If a conformant MUA does not have a certificate or secret key for the user, it should help the user to generate, acquire, or import them with minimum difficulty.
コンフォーマントMUAにユーザーに証明書または秘密キーがない場合、ユーザーが最小限の難易度で生成、取得、またはインポートするのに役立つはずです。
For S/MIME, the user SHOULD have both a signing-capable certificate and an encryption-capable certificate (and the corresponding secret keys). Using the same cryptographic key material for multiple algorithms (i.e., for both encryption and signing) has been the source of vulnerabilities in other (non-email) contexts (e.g., [DROWN] and [IKE]). The simplest way to avoid any comparable risk is to use distinct key material for each cryptographic algorithm. A conformant MUA that generates S/MIME certificates for the user MUST generate distinct S/MIME certificates to avoid possible cross-protocol key misuse: one for encryption and another for signing.
S/MIMEの場合、ユーザーは署名対応証明書と暗号化対応証明書（および対応するシークレットキー）の両方を持っている必要があります。複数のアルゴリズム（つまり、暗号化と署名の両方に）に同じ暗号化キー資料を使用することは、他の（非照度）コンテキスト（例：[drown]および[IKE]）の脆弱性の原因となっています。同等のリスクを回避する最も簡単な方法は、各暗号化アルゴリズムに個別のキーマテリアルを使用することです。ユーザーのS/MIME証明書を生成するコンフォーマントゥMUAは、クロスプロトコルの誤用の可能性を回避するために、異なるS/MIME証明書を生成する必要があります。
The simplest option for an S/MIME-capable MUA is for the MUA to permit the user to import a PKCS #12 [RFC7292] object that is expected to contain secret key material, end entity certificates for the user, and intermediate certification authority (CA) certificates that permit chaining from the end entity certificates to widely accepted trust anchors. A conformant MUA that imports such a PKCS #12 bundle SHOULD warn the user if the bundle contains an S/MIME certificate and corresponding secret key where the same secret key is used for both encryption and signing.
S/MIME対応MUAの最も単純なオプションは、MUAがユーザーが秘密のキー資料、ユーザーのエンティティ証明書、および最終エンティティ証明書からチェーンを許可する中級証明書（CA）証明書を含むと予想されるPKCS＃12 [RFC7292]オブジェクトをインポートできるようにすることです。このようなPKCS＃12バンドルをインポートするコンフォーマントMUAは、バンドルにS/MIME証明書と、暗号化と署名の両方に同じシークレットキーが使用されている場合に対応するシークレットキーが含まれている場合、ユーザーに警告する必要があります。
An S/MIME-capable MUA that has access to user certificates and their corresponding secret key material should also offer the ability to export those objects into a well-formed PKCS #12 object that could be imported into another MUA operated by the same user.
ユーザー証明書とそれらの対応するシークレットキー資料にアクセスできるS/MIME対応MUAは、同じユーザーが操作する別のMUAにインポートできる適切に形成されたPKCS＃12オブジェクトにそれらのオブジェクトをエクスポートする機能も提供するはずです。
Manual handling of PKCS #12 objects is challenging for most users. Producing the initial PKCS #12 object typically can only be done with the aid of a CA via non-standardized, labor-intensive, and error-prone procedures that most users do not understand. Furthermore, manual export and import incurs ongoing labor (for example, before certificate expiration) by the user, which most users are unprepared to do (see Section 8.2.2).
PKCS＃12オブジェクトの手動処理は、ほとんどのユーザーにとって困難です。最初のPKCS＃12オブジェクトの生成は、通常、ほとんどのユーザーが理解していない非標準化された、労働集約的な、エラーが発生しやすい手順を介してCAの助けを借りてのみ行うことができます。さらに、手動の輸出と輸入は、ほとんどのユーザーが行う準備ができていないユーザーによる継続的な労働（たとえば、証明書の有効期限の前）を被ります（セクション8.2.2を参照）。
A better approach is for the MUA to integrate some form of automated certificate issuance procedure, for example, by using the Automatic Certificate Management Environment (ACME) protocol for end user S/ MIME certificates [RFC8823].
より良いアプローチは、MUAが、たとえば、自動証明書管理環境（ACME）プロトコルを使用して、エンドユーザーS/ MIME証明書[RFC8823]を使用して、何らかの形の自動化された証明書発行手順を統合することです。
Another possible approach is integration with a cryptographic hardware token or smart card that can provide certificates and permit the use of isolated secret key material, for example, see [PKCS11], though this approach delegates the complexity of acquiring and managing certificates to management of the hardware token itself (see Appendix A.4.2).
別の可能なアプローチは、証明書を提供し、孤立したシークレットキー資料の使用を許可できる暗号化ハードウェアトークンまたはスマートカードとの統合です。たとえば、[PKCS11]を参照してください。このアプローチは、ハードウェアトークン自体の管理と管理の複雑さを委任します（付録A.4.2を参照）。
See also [CERT-BEST-PRACTICE] for more recommendations about managing user certificates.
ユーザー証明書の管理に関する詳細については、[Cert-Best-Practice]も参照してください。
As distinct from S/MIME, OpenPGP [RFC9580] has a different set of common practices. For one thing, a single OpenPGP certificate can contain both a signing-capable key and a distinct encryption-capable key, so only one certificate is needed for an email user of OpenPGP as long as the certificate has distinct key material for the different purposes.
S/MIMEとは異なるように、OpenPGP [RFC9580]には異なる共通の慣行があります。1つには、単一のOpenPGP証明書には、署名対応キーと個別の暗号化対応キーの両方を含めることができるため、証明書に異なる目的のために明確なキー資料がある限り、OpenPGPの電子メールユーザーには1つの証明書のみが必要です。
Furthermore, a single OpenPGP certificate MAY only be self-signed, so the MUA can generate such a certificate entirely on its own.
さらに、単一のOpenPGP証明書は自己署名のみである可能性があるため、MUAはそのような証明書を完全に自然に生成できます。
An OpenPGP-capable MUA should have the ability to import and export OpenPGP Transferable Secret Keys (see Section 10.2 of [RFC9580]) to enable manual transfer of user certificates and secret key material between multiple MUAs controlled by the user.
OpenPGP対応のMUAには、ユーザーが制御する複数のMUA間のユーザー証明書と秘密キー資料の手動転送を可能にするために、OpenPGP転送可能な秘密キーをインポートおよびエクスポートする機能（[RFC9580]のセクション10.2を参照）を使用する必要があります。
Since an OpenPGP certificate MAY be certified by third parties (whether formal CAs or merely other well-connected peers), the MUA SHOULD offer affordances to help the user acquire and merge third-party certifications on their certificate. When doing this, the MUA should prioritize third-party certifications from entities that the user's peers are likely to know about and be willing to rely on.
OpenPGP証明書は第三者（正式なCASまたは単に他のよく接続されたピアであろうと）によって認定される可能性があるため、MUAは、ユーザーが証明書のサードパーティ認定を獲得してマージするのを支援するためのアフォーダンスを提供する必要があります。これを行う際、MUAは、ユーザーのピアが知っている可能性が高いエンティティからのサードパーティ認定を優先し、頼りにする必要があります。
Since an OpenPGP certificate can grow arbitrarily large with third-party certifications, the MUA should assist the user in pruning it to ensure that it remains a reasonable size when transmitting it to other parties.
OpenPGP証明書はサードパーティの認定でarbitrarily意的に大きくなる可能性があるため、MUAはユーザーが剪定するのを支援して、他の当事者に送信するときに合理的なサイズのままであることを確認する必要があります。
Regardless of the protocol used (S/MIME or PGP), when producing certificates for the end user, the MUA SHOULD ensure that it has generated secret key material locally and MUST NOT accept secret key material from an untrusted external party as the basis for the user's certificate. For example, a user who trusts their system administrator not to compromise their MUA may accept secret key material generated by the system administrator but probably should not accept secret key material generated by an unaffiliated online web service.
使用されているプロトコル（S/MIMEまたはPGP）に関係なく、エンドユーザーの証明書を作成する場合、MUAは、秘密の鍵資料をローカルに生成し、ユーザーの証明書の基礎として信頼されていない外部当事者から秘密の鍵資料を受け入れてはなりません。たとえば、システム管理者がMUAを侵害しないと信頼するユーザーは、システム管理者によって生成された秘密の鍵資料を受け入れる可能性がありますが、おそらく、関係のないオンラインWebサービスによって生成された秘密の鍵資料を受け入れるべきではありません。
An MUA that accepts secret key material from a third party cannot prevent that third party from retaining this material. A third party with this level of access could decrypt messages intended to be confidential for the user or could forge messages that would appear to come from the user.
第三者から秘密の鍵資料を受け入れるMUAは、その第三者がこの資料を保持することを防ぐことはできません。このレベルのアクセスを備えたサードパーティは、ユーザーの機密を目的としたメッセージを復号化したり、ユーザーから来るように見えるメッセージを強要する可能性があります。
In the context of a single email account managed by an MUA, where that email account is expected to be able to use end-to-end cryptographic protections, the MUA SHOULD warn the user (or proactively fix the problem) when/if:
MUAが管理する単一の電子メールアカウントのコンテキストでは、その電子メールアカウントがエンドツーエンドの暗号化保護を使用できると予想されているため、MUAはユーザーに警告する（または問題を積極的に修正）する必要があります。
* For S/MIME, the user's own certificate set for the account does not include a valid, unexpired encryption-capable X.509 certificate and a valid, unexpired signature-capable X.509 certificate.
* S/MIMEの場合、アカウントのユーザー独自の証明書セットには、有効で期限切れのないエンコリプト対応X.509証明書と有効な期限切れの署名対応X.509証明書は含まれていません。
* For PGP/MIME, the user's own certificate does not include a valid, unexpired signing-capable key/subkey and a valid, unexpired encryption-capable key/subkey.
* PGP/MIMEの場合、ユーザー独自の証明書には、有効で期限切れのない署名対応のキー/サブキーと有効な期限切れのある暗号化対応キー/サブキーが含まれていません。
* Any of the user's own certificates for the account:
* アカウントのユーザー自身の証明書のいずれか：
- are due to expire in the next month (or at some other reasonable cadence).
- 来月（または他の合理的なケイデンス）に期限切れになる予定です。
- do not match the email address associated with the account in question.
- 問題のアカウントに関連付けられているメールアドレスと一致しないでください。
* Any of the user's own S/MIME certificates for the account:
* アカウントのユーザー自身のS/MIME証明書のいずれか：
- do not have a keyUsage extension.
- KeyUSAGE拡張機能はありません。
- do not contain an extendedKeyUsage extension.
- ExtendendedKeyUsage拡張機能は含まれていません。
- would be considered invalid by the MUA for any other reason if it were a peer certificate.
- それがピア証明書である場合、他の理由でMUAによって無効と見なされます。
An MUA that takes active steps to fix any of these problems before they arise is even more usable than one that just issues warnings, but guidance on how to do active certificate maintenance is beyond the scope of this document (see Appendix A.4.3).
これらの問題が発生する前に積極的な措置を講じるMUAは、警告を発するだけの問題よりもさらに使用可能ですが、アクティブな証明書のメンテナンスを行う方法に関するガイダンスは、このドキュメントの範囲を超えています（付録A.4.3を参照）。
If the MUA does find any of these issues and chooses to warn the user, it should use one aggregate warning with simple language that describes how the certificates might not be acceptable for other people and recommend a course of action that the user can take to remedy the problem.
MUAがこれらの問題のいずれかを見つけてユーザーに警告することを選択した場合、他の人に証明書が受け入れられない可能性があり、ユーザーが問題を解決するために取ることができる一連の行動を推奨する単純な言語で1つの集計警告を使用する必要があります。
When composing mail, a conformant MUA SHOULD include copies of the user's own certificates (and potentially other certificates) in each message to facilitate future communication, unless it has specific knowledge that the other parties involved already know the relevant keys (for example, if it is mail between members within a domain that has a synchronized and up-to-date certificate directory).
メールを作成する場合、コンフォーマントMUAには、関係する他の当事者が既に関連するキーを知っているという具体的な知識がない限り（たとえば、同期されています。ドメイン内のメンバー間のメンバー間のメールである場合、将来のコミュニケーションを促進するために、各メッセージにユーザー自身の証明書（および潜在的に他の証明書）のコピーを含める必要があります。
The mechanism for including these certificates, and which certificates to include in the message, are protocol specific.
これらの証明書を含めるためのメカニズム、およびメッセージに含める証明書は、プロトコル固有です。
In any S/MIME SignedData object, certificates can be shipped in the "certificates" member. In any S/MIME EnvelopedData object, certificates can be shipped in the "originatorInfo.certs" member.
S/MIME SignedDataオブジェクトでは、「証明書」メンバーに証明書を出荷できます。任意のS/MIME EnvelopedDataオブジェクトでは、「OriginatorInfo.Certs」メンバーに証明書を出荷できます。
When a single S/MIME-protected email message is signed-and-encrypted, it is usually sufficient to ship all the relevant certificates in the inner SignedData object's "certificates" member.
単一のs/mimeで保護された電子メールメッセージが署名され、暗号化されている場合、通常、内側のsigneddataオブジェクトの「証明書」メンバーに関連するすべての証明書を出荷するだけで十分です。
The S/MIME certificates shipped in such a message SHOULD include:
このようなメッセージに出荷されたS/MIME証明書には、以下を含める必要があります。
* the user's own S/MIME signing certificate, so that signature on the current message can be validated.
* ユーザー自身のS/MIME署名証明書。現在のメッセージの署名を検証できるように。
* the user's own S/MIME encryption-capable certificate, so that the recipient can reply in encrypted form.
* ユーザー自身のS/MIME暗号化対応証明書。
* on an encrypted message to multiple recipients, the encryption-capable peer certificates of the other recipients, so that any recipient can easily "reply all" without needing to search for certificates.
* 複数の受信者への暗号化されたメッセージで、他の受信者の暗号化対応のピア証明書を作成して、受信者が証明書を検索する必要なく簡単に「すべてに返信」できるようにします。
* any intermediate CA certificates needed to chain all of the above to a widely trusted set of root authorities.
* 上記のすべてを広く信頼されているルート当局に連れて行くのに必要な中間CA証明書。
PGP/MIME does not have a single specific standard location for shipping certificates.
PGP/MIMEには、配送証明書の特定の標準場所が1つありません。
Some MUAs ship relevant OpenPGP certificates in a single MIME leaf of Content-Type "application/pgp-keys". When such a message has cryptographic protections, to ensure that the message is well-formed, this kind of MIME part SHOULD be a leaf of the Cryptographic Payload and not outside of it. One problem with this approach is that it appears to recipients with non-cryptographic MUAs as an "attachment", which can lead to confusion if the user does not know how to use it.
一部のMUASは、コンテンツタイプの「アプリケーション/PGP-Keys」の単一のMIMEリーフに関連するOpenPGP証明書を出荷します。このようなメッセージに暗号化が保護されている場合、メッセージが適切に形成されていることを確認するために、この種のマイム部分は暗号化のペイロードの葉であり、その外側ではありません。このアプローチの問題の1つは、非暗号化されたMUAを持つ受信者には「添付ファイル」と見なされることです。これは、ユーザーがそれを使用する方法を知らない場合、混乱につながる可能性があります。
Other implementations ship relevant OpenPGP certificates in "Autocrypt" or "Autocrypt-Gossip" message header fields (see [AUTOCRYPT]). To ensure that those header fields receive the same cryptographic authenticity as the rest of the message, these header fields SHOULD be protected as described in [RFC9788].
その他の実装は、関連するOpenPGP証明書を「Autocrypt」または「Autocrypt-GossIP」メッセージヘッダーフィールドに出荷します（[AutoCrypt]を参照）。これらのヘッダーフィールドが、メッセージの残りの部分と同じ暗号化の信頼性を受け取るようにするには、[RFC9788]で説明されているように、これらのヘッダーフィールドを保護する必要があります。
The OpenPGP certificates shipped in such a message SHOULD include:
このようなメッセージに出荷されたOpenPGP証明書には、以下を含める必要があります。
* the user's own OpenPGP certificate, capable of both signing and encryption, so that the user can validate the message's signature and can encrypt future messages.
* ユーザーが署名と暗号化の両方が可能な独自のOpenPGP証明書を使用して、ユーザーがメッセージの署名を検証し、将来のメッセージを暗号化できるようにします。
* on an encrypted message to multiple recipients, the OpenPGP certificates of the other recipients, so that any recipient can easily "reply all" without needing to search for certificates.
* 複数の受信者への暗号化されたメッセージで、他の受信者のOpenPGP証明書を作成するため、受信者は証明書を検索する必要なく「すべてに返信する」ことができます。
This section highlights a few "pitfalls" and guidelines based on these discussions and lessons learned.
このセクションでは、これらの議論と学んだ教訓に基づいたいくつかの「落とし穴」とガイドラインを強調しています。
When sending a message, a typical MUA will store a copy of the message sent in sender's Sent mail folder so that the sender can read it later. If the message is an encrypted message, storing it encrypted requires some forethought to ensure that the sender can read it in the future.
メッセージを送信すると、典型的なMUAは、送信者の送信メールフォルダーに送信されたメッセージのコピーを保存して、送信者が後で読み取ることができます。メッセージが暗号化されたメッセージである場合、暗号化されたものを保存するには、送信者が将来それを読むことができることを確認するためにある程度の先見の明が必要です。
It is a common and simple practice to encrypt the message not only to the recipients of the message but also to the sender. One advantage of doing this is that the message that is sent on the wire can be identical to the message stored in the sender's Sent mail folder. This allows the sender to review and reread the message even though it was encrypted.
メッセージの受信者だけでなく、送信者にもメッセージを暗号化することは、一般的で簡単な慣行です。これを行うことの1つの利点は、ワイヤーに送信されるメッセージが、送信者の送信メールフォルダーに保存されているメッセージと同一である可能性があることです。これにより、送信者は暗号化されていてもメッセージをレビューして読み直すことができます。
There are at least three other approaches that are possible to ensure future readability by the sender of the message but with different trade-offs:
メッセージの送信者による将来の読みやすさを確保することができるが、異なるトレードオフを使用して、少なくとも3つの他のアプローチがあります。
* Encrypt two versions of the message: one to the recipients (this version is sent on the wire) and one to the sender only (this version is stored in the sender's Sent folder). This approach means that the message stored in the Sent folder is not byte-for-byte identical to the message sent to the recipients. In the event that message delivery has a transient failure, the MUA cannot simply resubmit the stored message into the SMTP system and expect it to be readable by the recipient.
* メッセージの2つのバージョンを暗号化します。1つは受信者（このバージョンはワイヤー上に送信されます）と1つは送信者のみに（このバージョンは送信者の送信フォルダーに保存されます）。このアプローチは、送信されたフォルダーに保存されているメッセージが、受信者に送信されたメッセージと同一のバイトではないことを意味します。メッセージ配信に一時的な障害がある場合、MUAは保存されたメッセージをSMTPシステムに単純に再提出し、受信者が読みやすいと期待することはできません。
* Store a cleartext version of the message in the Sent folder. This presents a risk of information leakage: Anyone with access to the Sent folder can read the contents of the message. Furthermore, in any attempt to resend the message, the cryptographic transformation needs to be reapplied before sending or else the message contents will leak upon resend. A conformant MUA SHOULD NOT store a cleartext copy in the Sent folder unless it knows that the Sent folder cannot be read by an attacker. For example, if end-to-end confidentiality is desired, then storing the cleartext in an IMAP folder where a potentially adversarial server can read it defeats the purpose.
* 送信されたフォルダーにメッセージのクリアテキストバージョンを保存します。これには、情報の漏れのリスクがあります。送信されたフォルダーにアクセスできる人なら誰でも、メッセージの内容を読むことができます。さらに、メッセージを再送信する試みでは、送信する前に暗号化の変換を再適用する必要があります。そうしないと、メッセージの内容が再送信されます。コンフォーマントMUAは、送信されたフォルダーが攻撃者が読み取れないことを知らない限り、送信フォルダーにクリアテキストコピーを保存しないでください。たとえば、エンドツーエンドの機密性が必要な場合は、潜在的に敵対的なサーバーが読み取ることができるIMAPフォルダーにClearTextを保存すると、目的を打ち負かします。
* A final option is that the MUA can store a copy of the message's encryption session key. Standard email encryption mechanisms (e.g., S/MIME and PGP/MIME) are hybrid mechanisms: The asymmetric encryption steps simply encrypt a symmetric "session key", which is used to encrypt the message itself. If the MUA stores the session key itself, it can use the session key to decrypt the Sent message without needing the Sent message to be decryptable by the user's own asymmetric key. An MUA doing this must take care to store (and backup) its stash of session keys, because if it loses them, it will not be able to read the sent messages; and if someone else gains access to them, they can decrypt the sent messages. This has the additional consequence that any other MUA accessing the same Sent folder cannot decrypt the message unless it also has access to the stashed session key.
* 最後のオプションは、MUAがメッセージの暗号化セッションキーのコピーを保存できることです。標準の電子メール暗号化メカニズム（S/MIMEおよびPGP/MIMEなど）はハイブリッドメカニズムです。非対称暗号化ステップは、メッセージ自体を暗号化するために使用される対称「セッションキー」を単純に暗号化するだけです。MUAがセッションキー自体を保存している場合、セッションキーを使用して、ユーザー自身の非対称キーによって送信されたメッセージを復号化できるようにする必要なく、送信されたメッセージを解読できます。これを行うMUAは、セッションキーの隠し場所を保存（およびバックアップする）に注意しなければなりません。なぜなら、それがそれらを失った場合、送信されたメッセージを読み取ることができないからです。そして、他の誰かが彼らにアクセスできるようになった場合、彼らは送信されたメッセージを解読することができます。これには、同じ送られたフォルダーにアクセスする他のMUAが、スタッシュセッションキーにもアクセスできない限り、メッセージを解読できないという追加の結果があります。
When encrypting a message, the composing MUA should decline to encrypt to an expired certificate (see Section 8.1.1). But when decrypting a message, as long as the viewing MUA has access to the appropriate secret key material, it should permit decryption of the message, even if the associated certificate is expired. That is, the rendering MUA should not prevent the user from reading a message that they have access to merely due to an expired encryption certificate.
メッセージを暗号化する場合、MUAの構成は期限切れの証明書に暗号化することを拒否する必要があります（セクション8.1.1を参照）。しかし、メッセージを復号化する場合、表示されているMUAが適切な秘密のキー資料にアクセスできる限り、関連する証明書の有効期限が切れていても、メッセージの復号化が許可されます。つまり、レンダリングMUAは、ユーザーが単に有効期限のある暗号化証明書のためにアクセスできるというメッセージを読み取らないようにするべきではありません。
The rendering MUA may warn the user when decrypting a message that appears to have been encrypted to an encryption-capable certificate that was expired at the time of encryption (e.g., based on the Date header field of the message or the timestamp in the cryptographic signature) but otherwise should not complain.
レンダリングMUAは、暗号化時に失効した暗号化対応証明書に暗号化されたように見えるメッセージを復号化するときにユーザーに警告するかもしれません（例えば、暗号化署名のメッセージの日付ヘッダーフィールドまたはタイムスタンプに基づいて）
The primary goal of certificate expiration is to facilitate rotation of secret key material, so that secret key material does not need to be retained indefinitely. Certificate expiration permits the user to destroy an older secret key if access to the messages encrypted to it is no longer necessary (see also Appendix A.10).
証明書の有効期限の主な目標は、秘密の鍵資料の回転を促進することです。そのため、秘密の鍵素材を無期限に保持する必要はありません。証明書の有効期限は、暗号化されたメッセージにアクセスしても、古いシークレットキーを破壊することができなくなります（付録A.10も参照）。
Many legacy cryptographically aware MUAs only apply cryptographic protections to the body of the message but leave the header fields unprotected. This gives rise to vulnerabilities like information leakage (e.g., the Subject line is visible to a passive intermediary) or message tampering (e.g., the Subject line is replaced, effectively changing the semantics of a signed message). These are not only security vulnerabilities but also usability problems, because the distinction between what is part of the header section and what is part of the body of a message is unclear to many end users and requires a more complex mental model than is necessary. Useful security comes from alignment between simple mental models and tooling.
多くのレガシーは暗号化されているMUASをメッセージの本体にのみ暗号化保護を適用するだけでなく、ヘッダーフィールドを保護されていないままにします。これにより、情報の漏れ（例えば、件名がパッシブ仲介業者に表示される）やメッセージの改ざん（例えば、件名が置き換えられ、署名されたメッセージのセマンティクスを効果的に変更する）などの脆弱性が生じます。これらはセキュリティの脆弱性だけでなく、ユーザビリティの問題でもあります。これは、ヘッダーセクションの一部とメッセージの本体の一部との区別が多くのエンドユーザーには不明であり、必要以上に複雑なメンタルモデルを必要とするためです。有用なセキュリティは、単純なメンタルモデルとツールの間のアラインメントから生まれます。
To avoid these concerns, a conformant MUA MUST implement Header Protection as described in [RFC9788].
これらの懸念を回避するために、[RFC9788]に記載されているように、適合MUAはヘッダー保護を実装する必要があります。
Note that some message header fields, such as List-*, Archived-At, and Resent-*, are typically added by an intervening MUA (see Section 9.8), not by one of the classic "ends" of an end-to-end email exchange. A rendering MUA may choose to consider the contents of these header fields on an end-to-end protected message as markers added during message transit, even if they are not covered by the end-to-end cryptographic protection.
list*、archived-at、resent-*などのメッセージヘッダーフィールドは、通常、介在するMUA（セクション9.8を参照）によって追加されることに注意してください。レンダリングMUAは、エンドツーエンドの暗号化保護でカバーされていなくても、メッセージトランジット中にマーカーが追加されたように、エンドツーエンドの保護されたメッセージでこれらのヘッダーフィールドの内容を考慮することを選択する場合があります。
When composing an encrypted message containing at least one recipient address in the Bcc header field, there is a risk that the encrypted message itself could leak information about the actual recipients, even if the Bcc header field does not mention the recipient. For example, if the message clearly indicates which certificates it is encrypted to, the set of certificates can identify the recipients even if they are not named in the message header fields.
BCCヘッダーフィールドに少なくとも1つの受信者アドレスを含む暗号化されたメッセージを作成する場合、BCCヘッダーフィールドが受信者に言及していなくても、暗号化されたメッセージ自体が実際の受信者に関する情報をリークできるリスクがあります。たとえば、メッセージが暗号化されている証明書を明確に示している場合、メッセージヘッダーフィールドに名前が付けられていなくても、証明書のセットが受信者を識別できます。
Because of these complexities, there are several interacting factors that need to be taken into account when composing an encrypted message with Bcc'ed recipients.
これらの複雑さのために、BCCの受信者と暗号化されたメッセージを作成する際に考慮する必要があるいくつかの相互作用要因があります。
* Should the Bcc header field be populated explicitly on Bcc'ed copies of the message and in the copy stored in the sender's Sent folder? See Section 3.6.3 of [RFC5322] for a set of choices.
* BCCヘッダーフィールドは、メッセージのBCCのコピーと、送信者の送信フォルダーに保存されているコピーに明示的に入力する必要がありますか？一連の選択については、[RFC5322]のセクション3.6.3を参照してください。
* When separate copies are made for Bcc'ed recipients, should each separate copy _also_ be encrypted to the named recipients or just to the designated Bcc recipient?
* BCCの受信者向けに個別のコピーが作成された場合、個別のコピーを各コピー_Also_を指定された受信者に暗号化する必要がありますか、それとも指定されたBCC受信者に単に暗号化する必要がありますか？
* When a copy is stored in the Sent folder, should that copy also be encrypted to Bcc'ed recipients? (See also Section 9.1.)
* コピーが送信フォルダーに保存されている場合、そのコピーはBCCの受信者にも暗号化される必要がありますか？（セクション9.1も参照してください。）
* When a message is encrypted, if there is a mechanism to include the certificates of the recipients, whose certificates should be included?
* メッセージが暗号化された場合、受信者の証明書を含めるメカニズムがある場合、証明書を含める必要がありますか？
Here is a simple approach that tries to minimize the total number of variants of the message created while leaving a coherent view of the message itself:
ここに、メッセージ自体の一貫したビューを残しながら作成されたメッセージのバリエーションの総数を最小限に抑えようとする単純なアプローチがあります。
* No Cryptographic Payload contains any Bcc header field.
* BCCヘッダーフィールドには、暗号化ペイロードが含まれていません。
* The main copy of the message is signed and encrypted to all named recipients and to the sender. A copy of this message is also stored in the sender's Sent folder.
* メッセージのメインコピーは署名され、すべての名前付き受信者と送信者に暗号化されます。このメッセージのコピーは、送信者の送信フォルダーにも保存されます。
* Each Bcc recipient receives a distinct copy of the message, with an identical Cryptographic Payload (that is, the cleartext is identical), and the message is signed and encrypted to that specific recipient and all the named recipients. These copies are not stored in the sender's Sent folder.
* 各BCCレシピエントは、同じ暗号化ペイロード（つまり、クリアテキストは同一です）を使用して、メッセージの明確なコピーを受け取り、メッセージに署名され、その特定の受信者とすべての指定された受信者に暗号化されます。これらのコピーは、送信者の送信フォルダーに保存されません。
* Any Bcc'ed recipient MUST NOT be taken into consideration when determining which certificates to include in the message. In particular, certificates for Bcc'ed recipients MUST NOT included in any message.
* メッセージにどの証明書を含めるかを決定する際に、BCCの受信者は考慮してはなりません。特に、BCCの受信者の証明書はメッセージに含まれてはなりません。
The approach described in Section 9.4.1 aligns the list of cryptographic recipients as closely as possible with the set of named recipients while still allowing a Bcc'ed recipient to read their own copy and to "reply all", should they want to.
セクション9.4.1で説明されているアプローチは、暗号化受信者のリストを、名前の受信者のセットと可能な限り密接に並べ、BCCの受信者が自分のコピーを読んで「すべてに返信する」ことを許可します。
This should reduce user confusion on the receiving side: A recipient of such a message who naively looks at the User-Facing Header Fields from their own mailbox will have a good sense of what cryptographic treatments have been applied to the message. It also simplifies message composition and user experience: The message composer sees fields that match their expectations about what will happen to the message. Additionally, it may preserve the ability for a Bcc'ed recipient to retain their anonymity, should they need to offer the signed Cryptographic Payload to an outside party as proof of the original sender's intent without revealing their own identity.
これにより、受信側のユーザーの混乱が減少するはずです。自分のメールボックスからユーザー向けのヘッダーフィールドを素朴に見るこのようなメッセージの受信者は、メッセージにどのような暗号化処理が適用されているかについて良い感覚を持っています。また、メッセージの構成とユーザーエクスペリエンスを簡素化します。メッセージ作曲家は、メッセージに何が起こるかについての期待に合ったフィールドを見ます。さらに、自分のアイデンティティを明らかにすることなく元の送信者の意図の証拠として、署名された暗号化ペイロードを外部の当事者に提供する必要がある場合、BCCの受信者が匿名性を保持する能力を維持する場合があります。
When composing a message, most MUAs will save a copy of the as-yet-unsent message to a "Drafts" folder. If that folder is itself stored somewhere not under the user's control (e.g., an IMAP mailbox), it would be a mistake to store the draft message in the clear, because its contents could leak.
メッセージを作成するとき、ほとんどのMUAは、まだまだ無セントなメッセージのコピーを「ドラフト」フォルダーに保存します。そのフォルダーがそれ自体がユーザーの制御下にない場所（例：IMAPメールボックス）に保存されている場合、その内容が漏れる可能性があるため、ドラフトメッセージをクリアに保存するのは間違いです。
This is the case even if the message is ultimately sent deliberately in the clear. During message composition, the MUA does not know whether the message is intended to be sent encrypted or not. For example, just before sending, the user could decide to encrypt the message, and the MUA would have had no way of knowing.
これは、メッセージが最終的に意図的に明確に送信されたとしてもそうです。メッセージの構成中、MUAはメッセージが暗号化されたものかどうかを意図しているかどうかを知りません。たとえば、送信する直前に、ユーザーはメッセージを暗号化することを決定することができ、MUAには知る方法がなかったでしょう。
The MUA SHOULD encrypt all draft messages, unless it has explicit knowledge that the message will not be encrypted when sent or that the Drafts folder cannot be read by an attacker. For example, if end-to-end confidentiality is desired, then storing a cleartext draft in an IMAP folder where a potentially adversarial server can read it defeats the purpose.
MUAは、送信時にメッセージが暗号化されないこと、または攻撃者がドラフトフォルダーを読み取ることができないという明示的な知識がない限り、すべてのドラフトメッセージを暗号化する必要があります。たとえば、エンドツーエンドの機密性が必要な場合は、潜在的に敵対的なサーバーが読み取ることができるIMAPフォルダーにクリアテキストドラフトを保存し、目的を打ち負かします。
Furthermore, when encrypting a draft message, the message draft MUST only be encrypted to the user's own certificate or to some equivalent secret key that only the user possesses. A draft message encrypted in this way can be decrypted when the user wants to resume composing the message but cannot be read by anyone else, including a potential intended recipient. Note that a draft message encrypted in this way will only be resumable by another MUA attached to the same mailbox if that other MUA has access to the user's decryption-capable secret key. This shared access to key material is also likely necessary for useful interoperability but is beyond the scope of this document (see Appendix A.4.1).
さらに、ドラフトメッセージを暗号化する場合、メッセージドラフトは、ユーザー自身の証明書またはユーザーのみが所有する同等のシークレットキーにのみ暗号化する必要があります。この方法で暗号化されたドラフトメッセージは、ユーザーがメッセージの作成を再開したい場合に復号化できますが、潜在的な意図された受信者を含む他の人が読むことはできません。この方法で暗号化されたドラフトメッセージは、他のMUAがユーザーの復号化対応のシークレットキーにアクセスできる場合、同じメールボックスに接続された別のMUAによってのみ再開できます。この主要な資料への共有アクセスは、有用な相互運用性のためにも必要ですが、このドキュメントの範囲を超えています（付録A.4.1を参照）。
A conformant MUA MUST NOT sign a message draft with the user's normal signing key, because creating a non-repudiable signature implies a commitment from the sender. If a signed draft message were to leak to the user's "Drafts" folder on some untrustworthy server, the server operator could claim that the user had committed to something that they had not yet decided to commit to. If draft signing is intended for cryptographic coordination between multiple MUAs of the same user, it should be negotiated with a different key (but see Appendix A.4.1).
コンフォーマントMUAは、ユーザーの通常の署名キーを使用してメッセージドラフトに署名してはなりません。これは、繰り返されない署名を作成することは送信者からのコミットメントを意味するためです。署名されたドラフトメッセージが、信頼できないサーバー上のユーザーの「ドラフト」フォルダーにリークする場合、サーバーオペレーターは、ユーザーがまだコミットすることを決定していないものにコミットしていたと主張することができます。ドラフト署名が同じユーザーの複数のMUA間の暗号化の調整を目的としている場合、別のキーと交渉する必要があります（ただし、付録A.4.1を参照）。
The message should only be encrypted to its recipients upon actually sending the message. No reasonable user expects their message's intended recipients to be able to read a message that is not yet complete.
メッセージは、実際にメッセージを送信する際に、受信者にのみ暗号化する必要があります。合理的なユーザーは、メッセージの意図した受信者がまだ完了していないメッセージを読み取ることができると期待していません。
When composing a message that the user intends to be encrypted, it's possible that some recipients will be unable to view an encrypted copy. For example, when Carol composes a message to Alice and Bob, Carol's MUA may be able to find a valid encryption-capable certificate for Alice, but none for Bob.
ユーザーが暗号化するつもりであるというメッセージを作成する場合、一部の受信者が暗号化されたコピーを表示できない可能性があります。たとえば、キャロルがアリスとボブにメッセージを作成すると、キャロルのMUAはアリスの有効な暗号化対応証明書を見つけることができますが、ボブにはありません。
In this situation, there are four possible strategies, each of which has a negative impact on the experience of using encrypted mail. Carol's MUA can:
この状況では、4つの可能な戦略があり、それぞれが暗号化されたメールを使用した経験に悪影響を及ぼします。キャロルのムアは：
1. send encrypted to Alice and Bob, knowing that Bob will be unable to read the message.
1. ボブがメッセージを読むことができないことを知って、アリスとボブに暗号化されたものを送信します。
2. send encrypted to Alice only, dropping Bob from the message recipient list.
2. アリスのみに暗号化されたものを送信し、メッセージ受信者リストからボブをドロップします。
3. send the message in the clear to both Alice and Bob.
3. アリスとボブの両方にクリアでメッセージを送信します。
4. send an encrypted copy of the message to Alice and a cleartext copy to Bob.
4. メッセージの暗号化されたコピーをアリスに送信し、クリアテキストコピーをボブに送信します。
Each of these strategies has different drawbacks.
これらの戦略にはそれぞれ異なる欠点があります。
The problem with approach 1 is that Bob will receive unreadable mail.
アプローチ1の問題は、ボブが読み取れないメールを受信することです。
The problem with approach 2 is that Carol's MUA will not send the message to Bob, despite Carol asking it to.
アプローチ2の問題は、キャロルが尋ねたにもかかわらず、キャロルのMUAがボブにメッセージを送信しないことです。
The problem with approach 3 is that Carol's MUA will not encrypt the message, despite Carol asking it to.
アプローチ3の問題は、キャロルが求めているにもかかわらず、キャロルのMUAがメッセージを暗号化しないことです。
Approach 4 has two problems:
アプローチ4には2つの問題があります。
1. Carol's MUA will release a cleartext copy of the message, despite Carol asking it to send the message encrypted.
1. キャロルは、キャロルが暗号化されたメッセージの送信を依頼したにもかかわらず、メッセージのクリアテキストコピーをリリースします。
2. If Alice wants to "reply all" to the message, she may not be able to find an encryption-capable certificate for Bob either. This puts Alice in an awkward and confusing position, one that users are unlikely to understand. In particular, if Alice's MUA is following the guidance about replies to encrypted messages in Section 5.4, having received an encrypted copy will make Alice's reply buffer behave in an unusual fashion.
2. アリスがメッセージに「すべてを返信」したい場合、彼女はボブの暗号化対応証明書を見つけることができないかもしれません。これにより、アリスは厄介で紛らわしい位置になります。ユーザーが理解する可能性は低いです。特に、AliceのMUAがセクション5.4で暗号化されたメッセージに対する返信に関するガイダンスに従っている場合、暗号化されたコピーを受け取ったことで、アリスの返信バッファーが異常な方法で動作します。
This is particularly problematic when the second recipient is not "Bob" but in fact a public mailing list or other visible archive, where messages are simply never encrypted.
これは、2番目の受信者が「ボブ」ではなく、実際には公開メーリングリストまたはメッセージが単に暗号化されない他の目に見えるアーカイブである場合に特に問題があります。
Carol is unlikely to understand the subtleties and negative downstream interactions involved with approaches 1 and 4, so presenting the user with those choices is not advised.
キャロルは、アプローチ1および4に伴う微妙な微妙さと否定的な下流の相互作用を理解する可能性は低いため、ユーザーにそれらの選択肢を提示することはお勧めしません。
The most understandable approach for an MUA with an active user is to ask the user (when they hit "send") to choose between approach 2 and approach 3. If the user declines to choose between 2 and 3, the MUA can drop them back to their message composition window and let them make alternate adjustments.
アクティブなユーザーを使用したMUAの最も理解できるアプローチは、ユーザー（「送信」を押したとき）にアプローチ2とアプローチ3を選択するように依頼することです。ユーザーが2と3の選択を拒否した場合、MUAはメッセージ構成ウィンドウに戻して代替調整を行うことができます。
See also further discussion of these scenarios in [CLEARTEXT-COPY].
[ClearText-Copy]のこれらのシナリオの詳細についても参照してください。
An implementer of end-to-end cryptographic protections may be tempted by a simple software design that piggybacks off of a mail protocol, like SMTP Submission [RFC6409], IMAP [RFC9051], or JSON Meta Application Protocol (JMAP) [RFC8621], to handle message assembly and interpretation. In such an architecture, a naive MUA speaks something like a "standard" protocol, like SMTP, IMAP, or JMAP, to a local proxy, and the proxy handles signing and encryption (outbound) and decryption and verification (inbound) internally on behalf of the user. While such a "pluggable" architecture has the advantage of likely being easy to apply to any MUA, it is problematic for the goals of end-to-end communication, especially in an existing cleartext ecosystem like email, where any given message might be unsigned or signed, cleartext or encrypted. In particular:
エンドツーエンドの暗号化保護の実装者は、SMTP提出[RFC6409]、IMAP [RFC9051]、またはJSONメタアプリケーションプロトコル（JMAP）[RFC8621]など、メールプロトコルのように、メールプロトコルからピギーバックするシンプルなソフトウェア設計によって誘惑される場合があります。このようなアーキテクチャでは、ナイーブMUAは、SMTP、IMAP、またはJMAPなどの「標準」プロトコルのようなものをローカルプロキシに話し、プロキシは署名と暗号化（アウトバウンド）、およびユーザーに代わって内部的に内部的に復号化と復号化と検証（インバウンド）を処理します。このような「プラグ可能な」アーキテクチャには、MUAに簡単に適用できるという利点がありますが、特に、特定のメッセージが符号なしまたは署名、クリアテキスト、または暗号化される可能性のある既存のクリアテキストエコシステムなど、エンドツーエンドのコミュニケーションの目標にとっては問題があります。特に：
* the user cannot easily and safely identify what protections any particular message has (including messages currently being composed) and
* ユーザーは、特定のメッセージが持っている保護（現在構成されているメッセージを含む）を簡単かつ安全に識別することはできません。
* the proxy itself is unaware of subtle nuances about the message that the MUA actually knows.
* プロキシ自体は、MUAが実際に知っているメッセージについての微妙なニュアンスに気付いていません。
With a trustworthy and well-synchronized side channel or protocol extension between the MUA and the proxy, it is possible to deploy such an implementation safely, but the requirement for the side channel or extension eliminates the universal deployability advantage of the scheme.
MUAとプロキシの間の信頼できる適性サイドチャネルまたはプロトコル拡張により、このような実装を安全に展開することが可能ですが、サイドチャネルまたは拡張の要件により、スキームのユニバーサル展開の利点が排除されます。
Similar concerns apply to any implementation bound by an API that operates on message objects alone, without any additional contextual parameters.
同様の懸念は、追加のコンテキストパラメーターなしで、メッセージオブジェクトのみで動作するAPIによって拘束された任意の実装にも適用されます。
This section attempts to document some of the inherent risks involved with such an architecture.
このセクションでは、このようなアーキテクチャに関連する固有のリスクのいくつかを文書化しようとします。
When composing and sending a message, the act of applying cryptographic protections has subtleties that cannot be directly expressed in the SMTP protocol used by Submission [RFC6409] or in any other simple protocol that hands off a cleartext message for further processing.
メッセージを作成して送信する場合、暗号化保護を適用する行為には、提出[RFC6409]またはさらなる処理のためにクリアテキストメッセージを配る他の単純なプロトコルで使用するSMTPプロトコルで直接表現できない微妙さがあります。
For example, the sender cannot indicate via SMTP whether or not a given message _should_ be encrypted (some messages, such as those sent to a publicly archived mailing list, are pointless to encrypt) or select among multiple certificates for a recipient, if they exist (see Section 8.1.1).
たとえば、送信者は、特定のメッセージが暗号化されている_should_（公開されているメーリングリストに送信されたメッセージなどのメッセージが無意味であるかどうかなど）か、または存在する場合は複数の証明書から選択するかどうか（セクション8.1.1を参照）かどうかをSMTPを介して示すことはできません（セクション8.1.1を参照）。
Likewise, because such a proxy only interacts with the message when it is ready to be sent, it cannot indicate back to the user _during message composition_ whether or not the message is able to be encrypted (that is, whether a valid certificate is available for each intended recipient). A message author may write an entirely different message if they know that it will be protected end-to-end; however, without this knowledge, the author is obliged to either write text that they presume will be intercepted or risk revealing sensitive content.
同様に、そのようなプロキシは、送信する準備ができたときにメッセージとのみ対話するため、メッセージを暗号化できるかどうか（つまり、有効な証明書が各受信者が利用できるかどうか）にユーザー_DuringメッセージComposition_に示すことはできません。メッセージ著者は、エンドツーエンドで保護されることを知っている場合、まったく異なるメッセージを書くことができます。ただし、この知識がなければ、著者は、傍受されると思われるテキストを書くか、敏感なコンテンツを明らかにするリスクがあります。
Even without encryption, deciding whether to sign or not (and which certificate to sign with, if more than one exists) is another choice that the proxy is ill-equipped to make. The common message-signing techniques either render a message unreadable by any non-cryptographic MUA (i.e., PKCS #7 signed-data) or appear as an attachment that can cause confusion to a naive recipient using a non-cryptographic MUA (i.e., multipart/signed). If the composer knows that the recipient will not check signatures, they may prefer to leave a cleartext message without a cryptographic signature at all.
暗号化がなくても、署名するかどうか（および複数の署名する証明書が存在する場合）を決定することは、プロキシが装備されていない別の選択です。一般的なメッセージ署名手法は、非暗号化MUA（すなわち、PKCS＃7署名されたデータ）によって読み取られないメッセージをレンダリングするか、非結晶MUA（つまり、マルチパート/署名）を使用して素朴な受信者に混乱を引き起こす可能性のあるアタッチメントとして表示されます。作曲家が受信者が署名をチェックしないことを知っている場合、暗号化の署名なしでクリアテキストメッセージをまったく残すことを好むかもしれません。
Furthermore, handling encryption properly depends on the context of any given message, which cannot be expressed by the MUA to the Submission proxy. For example, decisions about how to handle encryption and quoted or attributed text may depend on the cryptographic status of the message that is being replied to (see Section 5.4).
さらに、暗号化の取り扱いは、MUAによって提出プロキシに表現することはできません。たとえば、暗号化と引用または属性のテキストを処理する方法に関する決定は、返信されているメッセージの暗号化ステータスに依存する場合があります（セクション5.4を参照）。
Additionally, such a proxy would need to be capable of managing the user's own key and certificate (see Section 8.2). For example, how will the implementation indicate to the user when their own certificate is near expiry? How will any other error conditions be handled when communication with the user is needed?
さらに、このようなプロキシは、ユーザー自身のキーと証明書を管理できる必要があります（セクション8.2を参照）。たとえば、自分の証明書が有効期限に近い場合、実装はユーザーにどのように示しますか？ユーザーとの通信が必要な場合、他のエラー条件はどのように処理されますか？
While an extension to SMTP might be able to express all the necessary semantics that would allow a generic MUA to compose messages with standard cryptographic protections via a proxy, such an extension is beyond the scope of this document. See [SMIME-SENDER-EXTENSIONS] for an example of how an MUA using a proxy protocol might indicate signing and encryption instructions to its proxy.
SMTPの拡張機能は、一般的なMUAがプロキシを介して標準の暗号保護を含むメッセージを作成できるようにする必要なすべてのセマンティクスを表現できる場合がありますが、このような拡張機能はこのドキュメントの範囲を超えています。プロキシプロトコルを使用しているMUAが、そのプロキシへの署名と暗号化の指示をどのように示すかの例については、[Smime-Sender-Extensions]を参照してください。
When receiving and rendering a message, the process of indicating the cryptographic status of a message to the user requires subtleties that are difficult to offer from a straightforward IMAP (or Post Office Protocol (POP) [RFC1939] or JMAP) proxy.
メッセージを受信してレンダリングするとき、ユーザーにメッセージの暗号化ステータスを示すプロセスには、簡単なIMAP（または郵便局プロトコル（POP）[RFC1939]またはJMAP）プロキシから提供するのが難しい微妙さが必要です。
One approach such a proxy could take is to remove all the Cryptographic Layers from a well-formed message and to package a description of those layers into a special header field that the MUA can read. But this merely raises the question: What semantics need to be represented? For example:
このようなプロキシがとることができるアプローチの1つは、すべての暗号化レイヤーを、整形式のメッセージから削除し、それらのレイヤーの説明をMUAが読むことができる特別なヘッダーフィールドにパッケージ化することです。しかし、これは単に疑問を提起するだけです。どのセマンティクスを表現する必要がありますか？例えば：
* Was the message signed? If so, by whom? When?
* メッセージは署名されましたか？もしそうなら、誰によって？いつ？
* Should the details of the cryptographic algorithms used in any signatures found be indicated as well?
* 見つかった署名で使用される暗号化アルゴリズムの詳細も同様に示されるべきですか？
* Was the message encrypted? If so, to whom? What key was used to decrypt it?
* メッセージは暗号化されましたか？もしそうなら、誰に？それを解読するためにどのような鍵が使用されましたか？
* If both signed and encrypted, was the signing outside or inside the encryption?
* 署名と暗号化の両方が場合、暗号化の外側または内部で署名していましたか？
* How should Errant Cryptographic Layers (see Section 4.5) be dealt with?
* 誤った暗号化層（セクション4.5を参照）をどのように扱う必要がありますか？
* What cryptographic protections do the header fields of the message have? (See [RFC9788].)
* メッセージのヘッダーフィールドにはどのような暗号保護がありますか？（[RFC9788]を参照してください。）
* How are any errors or surprises communicated to the user?
* ユーザーにエラーや驚きはどのように伝えられていますか？
If the proxy passes any of this cryptographic status to the client in an added header field, it must also ensure that no such header field is present on the messages it receives before processing it. If it were to allow such an unmodified header field through to any client that is willing to trust its contents, an attacker could spoof the field to make the user believe lies about the cryptographic status of the message. In order for an MUA to be confident in such a header field, it needs a guarantee from the proxy that any header field it produces will be safe. How does the MUA reliably negotiate this guarantee with the proxy? If the proxy can no longer offer this guarantee, how will the MUA know that things have changed?
プロキシが追加されたヘッダーフィールドでこの暗号化ステータスのいずれかをクライアントに渡す場合、処理する前に受信するメッセージにそのようなヘッダーフィールドが存在しないことも保証する必要があります。そのような変更されていないヘッダーフィールドをそのコンテンツを信頼する意思のあるクライアントに許可する場合、攻撃者は、メッセージの暗号化ステータスについてユーザーに嘘をつくことをユーザーに信じさせることができます。MUAがこのようなヘッダーフィールドに自信を持つためには、プロキシから生成するヘッダーフィールドが安全であるという保証が必要です。MUAはこの保証をプロキシでどのように確実に交渉しますか？プロキシがもはやこの保証を提供できなくなった場合、MUAは物事が変わったことをどのように知るのでしょうか？
If such an inbound proxy handles certificate discovery in inbound messages (see Appendix A.3.1), it will also need to communicate the results of that discovery process to its corresponding outbound proxy for message composition (see Section 9.7.1).
このようなインバウンドプロキシがインバウンドメッセージの証明書の発見を処理する場合（付録A.3.1を参照）、メッセージ構成の対応するアウトバウンドプロキシにその発見プロセスの結果を伝える必要があります（セクション9.7.1を参照）。
While an extension to IMAP (or POP or JMAP) might be able to express all the necessary semantics that would allow a generic MUA to indicate standardized cryptographic message status, such an extension is beyond the scope of this document. [RFC9219] describes the transmission of an S/MIME signature verification status over JMAP, which is a subset of the cryptographic status information described here.
IMAP（またはPOPまたはJMAP）の拡張機能は、一般的なMUAが標準化された暗号化メッセージステータスを示すことを可能にする必要なすべてのセマンティクスを表現できる場合がありますが、このような拡張はこのドキュメントの範囲を超えています。[RFC9219]は、ここで説明する暗号化ステータス情報のサブセットであるJMAPを介したS/MIME署名検証ステータスの送信について説明しています。
Finally, consider that the naive proxy deployment approach is risky precisely because of its opacity to the end user. Such a deployment could be placed anywhere in the stack, including on a machine that is not ultimately controlled by the end user, making it effectively a form of transport protection rather than end-to-end protection.
最後に、エンドユーザーにとって不透明度のために、素朴なプロキシ展開アプローチはまさにリスクが高いことを考慮してください。このような展開は、エンドユーザーによって最終的に制御されていないマシンを含む、スタック内のどこにでも配置でき、エンドツーエンドの保護ではなく、事実上輸送保護の形式になります。
An MUA explicitly under the control of the end user with thoughtful integration can offer UI/UX and security guarantees that a simple proxy cannot provide. See also Appendix A.13 for suggestions of future work that might augment a proxy to make it safer.
思慮深い統合を備えたエンドユーザーの制御下にあるMUAは、UI/UXを提供し、簡単なプロキシが提供できないセキュリティ保証を提供できます。また、将来の作業の提案については、プロキシを強化してより安全にすることについては、付録A.13も参照してください。
Some MUAs will resend a message in identical form (or very similar form) to the way that they received it. For example, consider the following use cases:
一部のMUAは、受け取った方法と同じ形式（または非常に類似した形式）でメッセージを再送信します。たとえば、次のユースケースを検討してください。
* a mail expander or mailing list that receives a message and resends it to all subscribers (see also Appendix A.14 for more discussion of mailing lists)
* メッセージを受信してすべてのサブスクライバーに再送信するメールエキスパンダーまたはメーリングリスト（メーリングリストの詳細については、付録A.14も参照してください）
* an individual user who reintroduces a message they received into the mail transport system (see Section 3.6.6 of [RFC5322])
* 郵便輸送システムに受け取ったメッセージを再導入する個々のユーザー（[RFC5322]のセクション3.6.6を参照）
* an automated email intake system that forwards a report to the mailboxes of responsible staffers
* 責任者のスタッフのメールボックスにレポートを転送する自動電子メール摂取システム
These MUAs intervene in message transport by receiving and then reinjecting messages into the mail transport system. In some cases, the original sender or final recipient of a message that has passed through such an MUA may be unaware of the intervention. (Note that an MUA that forwards a received message as a attachment (MIME subpart) of type message/rfc822 or message/global or "inline" in the body of a message is _not_ acting as an intervening MUA in this sense, because the forwarded message is encapsulated within a visible outer message that is clearly from the MUA itself.)
これらのMUAは、メッセージを受信してからメールトランスポートシステムに再注入することにより、メッセージトランスポートに介入します。場合によっては、そのようなMUAを通過したメッセージの元の送信者または最終的な受信者は、介入に気付いていない可能性があります。（受信したメッセージをタイプメッセージ/RFC822またはメッセージ/グローバルまたは「インライン」の添付ファイル（MIMEサブパート）として転送するMUAは、この意味で介入するMUAとして機能する_NOT_であることに注意してください。
An intervening MUA should be aware of end-to-end cryptographic protections that might already exist on messages that they resend. In particular, it is unclear what the "end-to-end" properties are of a message that has been handled by an intervening MUA. For signed-only messages, if the intervening MUA makes any substantive modifications to the message as it passes it along, it may break the signature from the original sender. In many cases, breaking the original signature is the appropriate result, since the original message has been modified, and the original sender has no control over the modifications made by the intervening MUA. For signed-and-encrypted messages, if the intervening MUA is capable of decrypting the message, it must be careful when retransmitting the message. Will the new recipient be able to decrypt it? If not, will the message be useful to the recipient? If not, it may not make sense to resend the message.
介在するMUAは、再生するメッセージに既に存在する可能性のあるエンドツーエンドの暗号化保護を認識する必要があります。特に、「エンドツーエンド」プロパティが介入するMUAによって処理されたメッセージのものであることは不明です。署名のみのメッセージの場合、介在するMUAがメッセージを渡すときにメッセージを実質的に変更すると、元の送信者から署名を破る可能性があります。多くの場合、元のメッセージが変更されており、元の送信者は介入するMUAの変更を制御できないため、元の署名を破ることが適切な結果です。署名と暗号化されたメッセージの場合、介在するMUAがメッセージを復号化できる場合は、メッセージを再送信するときは注意する必要があります。新しい受信者はそれを解読することができますか？そうでない場合、メッセージは受信者に役立ちますか？そうでない場合は、メッセージを再送信することは意味がないかもしれません。
Beyond the act of resending, an intervening MUA should not itself try to apply end-to-end cryptographic protections on a message that it is resending unless directed otherwise by some future specification. Additional layers of cryptographic protection added in an ad hoc way by an intervening MUA are more likely to confuse the recipient and will not be interpretable as end-to-end protections as they do not originate with the original sender of the message.
復活の行為を超えて、介入するMUA自体は、将来の仕様に応じて指示されない限り、復活しているというメッセージにエンドツーエンドの暗号化保護を適用しようとするべきではありません。介在するMUAによってアドホックな方法で追加された暗号化保護の追加層は、受信者を混乱させる可能性が高く、メッセージの元の送信者から発生しないため、エンドツーエンドの保護として解釈できません。
A MIME part with a content type that can refer to external resources (like text/html) may itself have some sort of end-to-end cryptographic protections. However, retrieving or rendering these external resources may violate the properties that users expect from cryptographic protection.
外部リソース（テキスト/HTMLなど）を参照できるコンテンツタイプのMIMEパーツ自体には、何らかのエンドツーエンドの暗号化保護があります。ただし、これらの外部リソースを取得またはレンダリングすると、ユーザーが暗号化保護から期待するプロパティに違反する場合があります。
As a baseline, retrieving the external resource at the time a message is read can be used as a "web bug", leaking the activity and network location of the recipient to the server hosting the external resource. This privacy risk is present, of course, even for messages with no cryptographic protections but may be even more surprising to users who are shown some level of security indicator about a given message.
ベースラインとして、メッセージが読み取られる時点で外部リソースを「Webバグ」として取得し、外部リソースをホストするサーバーに受信者のアクティビティとネットワークの位置を漏らします。もちろん、このプライバシーリスクは、暗号化保護がないメッセージであっても存在しますが、特定のメッセージについてある程度のセキュリティインジケーターを示しているユーザーにとってはさらに驚くかもしれません。
Other problems with external resources are more specifically bound to cryptographic protections.
外部リソースに関する他の問題は、暗号化の保護に具体的に拘束されます。
For example, a signed email message with a text/html part that refers to an external image (i.e., via <img src="https://example.com/ img.png">) may render differently if the hosting web server decides to serve different content at the source URL for the image. This effectively breaks the goals of integrity and authenticity that the user should be able to rely on for signed messages, unless the external subresource has strict integrity guarantees (e.g., via [SRI]).
たとえば、外部画像を指すテキスト/HTMLパーツを含む署名された電子メールメッセージ（つまり、<img src = "https://example.com/ img.png">）を介して、ホスティングWebサーバーが画像のソースURLで異なるコンテンツを提供することを決定する場合、異なるレンダリングを行うことがあります。これにより、外部のサブリソースに厳格な整合性保証がない限り（[SRI]を介して）、ユーザーが署名されたメッセージに依存できる整合性と信頼性の目標を効果的に破ります。
Likewise, fetching an external subresource for a signed-and-encrypted message effectively breaks goals of privacy and confidentiality for the user.
同様に、署名と暗号化されたメッセージの外部サブリソースを取得すると、ユーザーのプライバシーと機密性の目標を効果的に破ります。
This is loosely analogous to security indicator problems that arose for web browsers as described in [MIXED-CONTENT]. However, while fetching the external subresource over https is sufficient to avoid a "mixed content" warning from most browsers, it is insufficient for an MUA that wants to offer its users true end-to-end guarantees for email messages.
これは、[混合コンテンツ]で説明されているように、Webブラウザーに発生するセキュリティインジケーターの問題に大まかに類似しています。ただし、ほとんどのブラウザからの「混合コンテンツ」警告を回避するには、HTTPSを介して外部サブリソースを取得するだけで十分ですが、ユーザーに電子メールメッセージの真のエンドツーエンドの保証を提供したいMUAにとっては不十分です。
A conformant composing MUA that applies signing-only cryptographic protection to a new email message with an external subresource should take one of the following options:
外部サブリソースを使用して新しい電子メールメッセージに署名のみの暗号保護を適用するコンフォーマント構成MUAは、次のオプションのいずれかをとる必要があります。
* pre-fetch the external subresource and include it in the message itself,
* 外部サブリソースを事前にフェッチし、メッセージ自体に含める、
* use a strong integrity mechanism like Subresource Integrity [SRI] to guarantee the content of the subresource (though this does not fix the "web bug" privacy risk described above), or
* サブリソースの整合性[SRI]などの強力な整合性メカニズムを使用して、サブリソースの内容を保証します（ただし、これは上記の「Webバグ」プライバシーリスクを修正しません）、または
* prompt the composing user to remove the subresource from the message.
* 構成ユーザーに、メッセージからサブリソースを削除するように促します。
A conformant composing MUA that applies encryption to a new email message with an external resource cannot depend on Subresource Integrity to protect the privacy and confidentiality of the message, so it should either pre-fetch the external resource to include it in the message or prompt the composing user to remove it before sending.
外部リソースを使用して新しい電子メールメッセージに暗号化を適用するコンフォーマントコンポーシングMUAは、メッセージのプライバシーと機密性を保護するためにサブリソースの整合性に依存することはできません。
A conformant rendering MUA that encounters a message with end-to-end cryptographic protections that contain a subresource MUST either refuse to retrieve and render the external subresource or decline to treat the message as having cryptographic protections. For example, it could indicate in the Cryptographic Summary that the message is Unprotected.
サブリソースを含むエンドツーエンドの暗号化保護でメッセージに遭遇するコンフォーマントレンダリングMUAは、外部サブリソースの取得とレンダリングを拒否するか、暗号化保護を持つとメッセージの扱いを拒否する必要があります。たとえば、暗号化の概要で、メッセージが保護されていないことを示すことができます。
Note that when composing a message reply with quoted text from the original message, if the original message did contain an external resource, the composing MUA SHOULD NOT fetch the external resource solely to include it in the reply message, as doing so would trigger the "web bug" at reply composition time. Instead, the safest way to deal with quoted text that contains an external resource in an end-to-end encrypted reply is to strip any reference to the external resource during initial composition of the reply.
元のメッセージから引用されたテキストでメッセージの返信を構成する場合、元のメッセージに外部リソースが含まれている場合、構成MUAは、返信メッセージにそれを含めるためだけに外部リソースを取得するべきではないことに注意してください。代わりに、エンドツーエンドの暗号化された応答に外部リソースを含む引用されたテキストを扱う最も安全な方法は、返信の初期構成中に外部リソースへの参照を削除することです。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This entire document addresses security considerations about end-to-end cryptographic protections for email messages.
このドキュメント全体は、電子メールメッセージのエンドツーエンドの暗号化保護に関するセキュリティに関する考慮事項について説明しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156,
DOI 10.17487/RFC3156, August 2001,
<https://www.rfc-editor.org/info/rfc3156>.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
<https://www.rfc-editor.org/info/rfc4289>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC9598] Melnikov, A., Chuang, W., and C. Bonnell,
"Internationalized Email Addresses in X.509 Certificates",
RFC 9598, DOI 10.17487/RFC9598, May 2024,
<https://www.rfc-editor.org/info/rfc9598>.
[RFC9788] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header
Protection for Cryptographically Protected Email",
RFC 9788, DOI 10.17487/RFC9788, August 2025,
<https://www.rfc-editor.org/info/rfc9788>.
[AUTOCRYPT]
Autocrypt Team, "Autocrypt - Convenient End-to-End
Encryption for E-Mail", <https://autocrypt.org/>.
[CERT-BEST-PRACTICE]
Woodhouse, D. and N. Mavrogiannopoulos, "Recommendations
for applications using X.509 client certificates", Work in
Progress, Internet-Draft, draft-woodhouse-cert-best-
practice-01, 25 July 2023,
<https://datatracker.ietf.org/doc/html/draft-woodhouse-
cert-best-practice-01>.
[CHROME-INDICATORS]
Schechter, E., "Evolving Chrome's security indicators",
Chromium Blog, May 2018,
<https://blog.chromium.org/2018/05/evolving-chromes-
security-indicators.html>.
[CLEARTEXT-COPY]
Gillmor, D. K., "Encrypted E-mail with Cleartext Copies",
Work in Progress, Internet-Draft, draft-dkg-mail-
cleartext-copy-01, 21 February 2023,
<https://datatracker.ietf.org/doc/html/draft-dkg-mail-
cleartext-copy-01>.
[DROWN] Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N.,
Dankel, M., Steube, J., Valenta, L., Adrian, D.,
Halderman, J. A., Dukhovni, V., Käsper, E., Cohney, S.,
Engels, S., Paar, C., and Y. Shavitt, "DROWN: Breaking TLS
using SSLv2", Proceedings of the 25th USENIX Security
Symposium (USENIX Security 16), pp. 689-706, August 2016,
<https://drownattack.com/drown-attack-paper.pdf>.
[EFAIL] Poddebniak, D., Dresen, C., Müller, J., Ising, F.,
Schinzel, S., Friedberger, S., Somorovsky, J., and J.
Schwenk, "Efail: Breaking S/MIME and OpenPGP Email
Encryption using Exfiltration Channels", Proceedings of
the 27th USENIX Security Symposium (USENIX Security 18),
pp. 549-566, August 2018,
<https://www.usenix.org/conference/usenixsecurity18/
presentation/poddebniak>.
[IKE] Felsch, D., Grothe, M., Schwenk, J., Czubak, A., and M.
Szymane, "The Dangers of Key Reuse: Practical Attacks on
IPsec IKE", Proceedings of the 27th USENIX Security
Symposium, pp. 567-583, August 2018,
<https://www.usenix.org/system/files/conference/
usenixsecurity18/sec18-felsch.pdf>.
[MIXED-CONTENT]
Stark, E., Ed., West, M., Ed., and C. Lopez, Ed., "Mixed
Content", W3C Candidate Recommendation Draft, February
2023,
<https://www.w3.org/TR/2023/CRD-mixed-content-20230223/>.
Latest version available at
<https://www.w3.org/TR/mixed-content/>.
[OPENPGP-FORWARDING]
Wussler, A., "Automatic Forwarding for ECDH Curve25519
OpenPGP messages", Work in Progress, Internet-Draft,
draft-wussler-openpgp-forwarding-00, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-wussler-
openpgp-forwarding-00>.
[ORACLE] Ising, F., Poddebniak, D., Kappert, T., Saatjohann, C.,
and S. Schinzel, "Content-Type: multipart/oracle - Tapping
into Format Oracles in Email End-to-End Encryption",
Proceedings of the 32nd USENIX Security Symposium (USENIX
Security 23), pp. 4175-4192, August 2023,
<https://www.usenix.org/conference/usenixsecurity23/
presentation/ising>.
[PKCS11] Bong, D., Ed. and T. Cox, Ed., "PKCS #11 Specification
Version 3.1", OASIS Standard, July 2023,
<https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/os/
pkcs11-spec-v3.1-os.html>.
[REPLY] Müller, J., Brinkmann, M., Poddebniak, D., Schinzel, S.,
and J. Schwenk, "Re: What's Up Johnny?: Covert Content
Attacks on Email End-to-End Encryption", Applied
Cryptography and Network Security (ACNS 2019), Lecture
Notes in Computer Science, vol. 11464, pp. 24-42,
DOI 10.1007/978-3-030-21568-2_2, April 2019,
<https://doi.org/10.1007/978-3-030-21568-2_2>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<https://www.rfc-editor.org/info/rfc1939>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3274] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274,
DOI 10.17487/RFC3274, June 2002,
<https://www.rfc-editor.org/info/rfc3274>.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
<https://www.rfc-editor.org/info/rfc3370>.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511,
DOI 10.17487/RFC4511, June 2006,
<https://www.rfc-editor.org/info/rfc4511>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
and M. Scott, "PKCS #12: Personal Information Exchange
Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
<https://www.rfc-editor.org/info/rfc7292>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities
(DANE) Bindings for OpenPGP", RFC 7929,
DOI 10.17487/RFC7929, August 2016,
<https://www.rfc-editor.org/info/rfc7929>.
[RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to
Associate Certificates with Domain Names for S/MIME",
RFC 8162, DOI 10.17487/RFC8162, May 2017,
<https://www.rfc-editor.org/info/rfc8162>.
[RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application
Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621,
August 2019, <https://www.rfc-editor.org/info/rfc8621>.
[RFC8823] Melnikov, A., "Extensions to Automatic Certificate
Management Environment for End-User S/MIME Certificates",
RFC 8823, DOI 10.17487/RFC8823, April 2021,
<https://www.rfc-editor.org/info/rfc8823>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>.
[RFC9216] Gillmor, D. K., Ed., "S/MIME Example Keys and
Certificates", RFC 9216, DOI 10.17487/RFC9216, April 2022,
<https://www.rfc-editor.org/info/rfc9216>.
[RFC9219] Melnikov, A., "S/MIME Signature Verification Extension to
the JSON Meta Application Protocol (JMAP)", RFC 9219,
DOI 10.17487/RFC9219, April 2022,
<https://www.rfc-editor.org/info/rfc9219>.
[RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe,
"OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024,
<https://www.rfc-editor.org/info/rfc9580>.
[SMIME-SENDER-EXTENSIONS]
Melnikov, A., "JMAP extension for S/MIME signing and
encryption", Work in Progress, Internet-Draft, draft-ietf-
jmap-smime-sender-extensions-04, 3 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-jmap-
smime-sender-extensions-04>.
[SPOOFING] Müller, J., Brinkmann, M., Poddebniak, D., Böck, H.,
Schinzel, S., Somorovsky, J., and J. Schwenk, ""Johnny,
you are fired!" - Spoofing OpenPGP and S/MIME Signatures
in Emails", Proceedings of the 28th USENIX Security
Symposium (USENIX Security 19), pp. 1011-1028, August
2019,
<https://www.usenix.org/system/files/sec19-muller.pdf>.
[SRI] Akhawe, D., Braun, F., Marier, F., and J. Weinberger,
"Subresource Integrity", W3C Candidate Recommendation,
June 2016, <https://www.w3.org/TR/2016/REC-SRI-20160623/>.
Latest version available at <https://www.w3.org/TR/SRI/>.
[WEBKEY-SERVICE]
Koch, W., "OpenPGP Web Key Directory", Work in Progress,
Internet-Draft, draft-koch-openpgp-webkey-service-20, 2
June 2025, <https://datatracker.ietf.org/doc/html/draft-
koch-openpgp-webkey-service-20>.
This document contains useful guidance for MUA implementers, but it cannot contain all possible guidance. Future revisions of this document may want to further explore the following topics, which are out of scope for this version.
このドキュメントには、MUA実装者にとって有用なガイダンスが含まれていますが、すべての可能なガイダンスを含めることはできません。このドキュメントの将来の改訂は、このバージョンの範囲外の次のトピックをさらに調査したい場合があります。
The webmail threat model for end-to-end cryptographic protections is significantly more complex than the classic MUA model. For example, the web server hosting the webmail interface could be a potential adversary. If the user treats the web server as a trusted party, but the web server violates that trust, the end-to-end cryptographic protections do not hold.
エンドツーエンドの暗号化保護のウェブメールの脅威モデルは、古典的なMUAモデルよりもはるかに複雑です。たとえば、WebメールインターフェイスをホストするWebサーバーは、潜在的な敵になる可能性があります。ユーザーがWebサーバーを信頼できるパーティーとして扱いますが、Webサーバーがその信頼を侵害している場合、エンドツーエンドの暗号化保護は保持されません。
A future version of this document could include more detailed discussion of an adversarial threat model for end-to-end cryptographic protections in a webmail context.
このドキュメントの将来のバージョンには、ウェブメールのコンテキストでのエンドツーエンドの暗号保護のための敵対的な脅威モデルのより詳細な議論が含まれます。
A future version of this document (or a companion document) could contain examples of well-formed and malformed messages using cryptographic key material and certificates from [RFC9580] and [RFC9216].
このドキュメント（またはコンパニオンドキュメント）の将来のバージョンには、[RFC9580]および[RFC9216]の暗号化キー資料と証明書を使用して、よく形成された不正なメッセージの例を含めることができます。
It may also include example renderings of these messages.
また、これらのメッセージのレンダリングの例を含めることもできます。
As described in Section 8.2.3, an incoming email message may have one or more certificates embedded in it. This document currently acknowledges that a rendering MUA should assemble a cache of certificates for future use, but providing more detailed guidance for how to assemble and manage that cache is currently out of scope.
セクション8.2.3で説明されているように、着信電子メールメッセージには1つ以上の証明書が埋め込まれている場合があります。現在、このドキュメントは、レンダリングMUAが将来の使用のために証明書のキャッシュを組み立てる必要があることを認めていますが、そのキャッシュを組み立てて管理する方法については、現在範囲外であることを認めています。
Existing recommendations like [AUTOCRYPT] provide some guidance for handling incoming certificates about peers but only in certain contexts. A future version of this document may describe in more detail how these incoming certificates should be handled.
[Autocrypt]などの既存の推奨事項は、特定のコンテキストでのみ、ピアに関する着信証明書を処理するためのガイダンスを提供します。このドキュメントの将来のバージョンは、これらの着信証明書をどのように処理するかをより詳細に説明する場合があります。
Some MUAs may have the capability to look up peer certificates in a directory, for example, via the Lightweight Directory Access Protocol (LDAP) [RFC4511], Web Key Directory (WKD) [WEBKEY-SERVICE], or DNS (e.g., SMIMEA [RFC8162] or OPENPGPKEY [RFC7929] resource records).
一部のMUAには、たとえばLightweight Directory Access Protocol（LDAP）[RFC4511]、Web Key Directory（WKD）[WebKey-Service]、またはDNS（例えば、Smimea [RFC8162]またはOpenPgkey [RFC7929]リソースレコード）を介して、ディレクトリ内のピア証明書を検索する機能がある場合があります。
A future version of this document may describe in more detail what sources an MUA should consider when searching for a peer's certificates and what to do with the certificates found by various methods.
このドキュメントの将来のバージョンは、ピアの証明書を検索する際にMUAが考慮すべき情報源と、さまざまな方法で見つかった証明書をどうするかをより詳細に説明する場合があります。
A future version of this document could discuss how/when to check for revocation of peer certificates or of the user's own certificate.
このドキュメントの将来のバージョンでは、ピア証明書またはユーザー自身の証明書の取り消し方法/時期を議論することができます。
Such discussion should address privacy concerns: What information leaks to whom when checking peer certificate revocations?
そのような議論は、プライバシーの懸念に対処する必要があります。ピア証明書の取り消しをチェックする際に誰に漏れますか？
A future version of this document may describe more prescriptions for deciding whether a peer certificate is acceptable for encrypting a message. For example, if the SPKI is an Elliptic Curve (EC) public key and the keyUsage extension is absent, what should the encrypting MUA do?
このドキュメントの将来のバージョンは、メッセージを暗号化するためにピア証明書が受け入れられるかどうかを決定するためのより多くの処方箋を説明する場合があります。たとえば、SPKIが楕円曲線（EC）の公開キーであり、KeyUSAGE拡張が存在しない場合、MUAを暗号化することは何をすべきでしょうか？
A future version of this document might also provide guidance on what to do if multiple certificates are all acceptable for encrypting to a given recipient. For example, the composing MUA could select among them in some deterministic way; it could encrypt to all of them; or it could present them to the user to let the user select any or all of them.
このドキュメントの将来のバージョンは、特定の受信者に暗号化するために複数の証明書がすべて許容できる場合のガイダンスを提供する場合があります。たとえば、構成MUAは、いくつかの決定論的な方法でそれらを選択できます。それらすべてに暗号化できます。または、ユーザーがそれらのいずれかまたはすべてを選択できるようにするためにユーザーに提示することもできます。
In header fields such as From that may contain a display-name as described in Section 3.4 of [RFC5322], a malicious composer (or interfering adversary) may populate the display-name part with a human-readable name that does not at all match the actual name of the participant. Section 8.1.1 describes some matching rules relating peer certificates to email addresses (the addr-spec part of these email header fields) but does not contemplate matching display-names or other similar user-visible data elements. Section 6.4 describes how signature validation should confirm a binding between the addr-spec and the certificate itself, but it also does not contemplate matching display-names or other similar user-visible data elements. Depending on how the rendering MUA renders the display-name in a message's header field, that unvalidated field may present a risk of user confusion, which could break the intended end-to-end assurances. Yet both X.509 and OpenPGP certificate formats offer ways to provide cryptographically certified (though possibly not unique) comparable human-readable names. Additionally, many MUAs also include an address book or comparable feature that can make substantive connections between user-relevant identity labels and email addresses.
[RFC5322]のセクション3.4で説明されているディスプレイ名を含む可能性のあるヘッダーフィールドでは、悪意のある作曲家（または干渉する敵）が、参加者の実際の名前とまったく一致しない人間の読み取り可能な名前にディスプレイ名の部分を埋めることができます。セクション8.1.1では、ピア証明書を電子メールアドレス（これらの電子メールヘッダーフィールドのADDRスペック部分）に関連付けるいくつかのマッチングルールについて説明しますが、ディスプレイ名またはその他の同様のユーザー可視データ要素を検討していません。セクション6.4では、署名検証がADDR-SPECと証明書自体の間のバインディングをどのように確認するかについて説明しますが、それはまた、一致するディスプレイ名または他の類似のユーザー可視データ要素を熟考していません。レンダリングMUAがメッセージのヘッダーフィールドでディスプレイ名をレンダリングする方法に応じて、その検証されていないフィールドはユーザーの混乱のリスクをもたらす可能性があり、意図したエンドツーエンドの保証を破る可能性があります。しかし、X.509とOpenPGP証明書形式の両方は、暗号化された（おそらくユニークではありませんが）同等の人間読み取り可能な名前を提供する方法を提供します。さらに、多くのMUAには、ユーザー関連のアイデンティティラベルとメールアドレスとの間に実質的な接続を作成できるアドレス帳または同等の機能も含まれています。
A human-readable name like a display-name does not have the property of global uniqueness that an addr-spec does, so reasoning about human-readable names and rendering them to the user as an element in a system providing end-to-end cryptographic assurance requires additional deliberate analysis.
ディスプレイ名のような人間の読み取り可能な名前には、ADDR-Specが行うグローバルユニークさのプロパティがないため、人間の読み取り可能な名前について推論し、エンドツーエンドの暗号化保証を提供するシステムの要素としてユーザーにレンダリングするには、追加の慎重な分析が必要です。
A future version of this document might offer strategies for associating human-readable names from certificates (and features like address books) to the rendering of header fields that include display-name. Such guidance should be paired with an analysis of specific usability and security risks associated with these human-readable fields, as well as a description of how the recommended guidance mitigates those risks.
このドキュメントの将来のバージョンは、証明書（およびアドレス帳などの機能）からディスプレイ名を含むヘッダーフィールドのレンダリングに関連する人間の読み取り可能な名前を関連付けるための戦略を提供する場合があります。このようなガイダンスは、これらの人間の読み取り可能な分野に関連する特定のユーザビリティとセキュリティリスクの分析と、推奨されるガイダンスがこれらのリスクをどのように軽減するかの説明と組み合わせる必要があります。
Many users today use more than one MUA to access the same mailbox (for example, one MUA on a mobile device and another MUA on a desktop computer).
今日、多くのユーザーは複数のMUAを使用して同じメールボックスにアクセスします（たとえば、モバイルデバイス上の1つのMUA、デスクトップコンピューターの別のMUA）。
A future version of this document might offer guidance on how multiple MUAs attached to the same mailbox can efficiently and securely share the user's own secret key material and certificates between each other. This guidance should include suggestions on how to maintain the user's keys (e.g., avoiding certificate expiration) and safe secret key transmission.
このドキュメントの将来のバージョンは、同じメールボックスに接続された複数のMUAが、ユーザー自身の秘密の鍵資料と互いの間でどのように安全に安全に共有できるかについてのガイダンスを提供する場合があります。このガイダンスには、ユーザーのキーを維持する方法（例：証明書の有効期限を避ける）と安全な秘密のキー送信に関する提案を含める必要があります。
Rather than having to transfer secret key material between clients, some users may prefer to rely on portable hardware-backed secret keys in the form of smart cards, USB tokens, or other comparable form factors. These secret keys sometimes require direct user interaction for each use, which can complicate the usability of any MUA that uses them to decrypt a large number of messages.
クライアント間で秘密のキー資料を転送するのではなく、一部のユーザーは、スマートカード、USBトークン、またはその他の同等のフォームファクターの形で、ポータブルハードウェア支援のシークレットキーに依存することを好む場合があります。これらの秘密のキーは、使用するたびに直接ユーザーインタラクションを必要とする場合があります。これにより、それらを使用して多数のメッセージを復号化するMUAの使いやすさが複雑になります。
Guidance on the use of this kind of secret key management is beyond the scope of this document, but future revisions may bring them into scope.
この種の秘密のキー管理の使用に関するガイダンスは、このドキュメントの範囲を超えていますが、将来の改訂はそれらを範囲に導く可能性があります。
Section 8.2.2 describes conditions where the MUA SHOULD warn the user that something is going wrong with their certificate.
セクション8.2.2では、MUAが証明書に何か問題が発生していることをユーザーに警告する条件について説明します。
A future version of this document might outline how an MUA could actively avoid these warning situations, for example, by automatically updating the certificate or prompting the user to take specific action.
このドキュメントの将来のバージョンは、MUAがこれらの警告状況を積極的に回避する方法を概説する可能性があります。たとえば、証明書を自動的に更新するか、ユーザーに特定のアクションを実行するように促します。
A future document could offer guidance on how an MUA should select and manage root CAs.
将来のドキュメントは、MUAがルートCAを選択および管理する方法に関するガイダンスを提供できます。
For example:
例えば：
* Should the MUA cache intermediate CAs?
* MUAは中間CASをキャッシュする必要がありますか？
* Should the MUA share such a cache with other PKI clients (e.g., web browsers)?
* MUAは、そのようなキャッシュを他のPKIクライアント（例：Webブラウザー）と共有する必要がありますか？
* What distinctions are there between a CA for S/MIME and a CA for the Web?
* S/MIME用のCAとWeb用のCAの間にはどのような区別がありますか？
A common use case for MUAs is the search of existing messages by keyword or topic. This is done most efficiently for large mailboxes by assembling an index of message content rather than by a linear scan of all message content.
MUASの一般的なユースケースは、キーワードまたはトピックによる既存のメッセージの検索です。これは、すべてのメッセージコンテンツの線形スキャンではなく、メッセージコンテンツのインデックスを組み立てることにより、大きなメールボックスで最も効率的に行われます。
When message contents and header fields are encrypted, search by index is complicated. If the cleartext is not indexed, then messages cannot be found by search. On the other hand, if the cleartext is indexed, then the index effectively contains the sensitive contents of the message and needs to be protected.
メッセージの内容とヘッダーフィールドが暗号化されると、インデックスごとの検索が複雑になります。ClearTextがインデックス化されていない場合、検索でメッセージを見つけることはできません。一方、ClearTextがインデックス化されている場合、インデックスにはメッセージの機密コンテンツが効果的に含まれているため、保護する必要があります。
Detailed guidance on the trade-off here, including choices about remote search vs. local search, are beyond the scope of this document, but a future version of the document may bring them into scope.
リモート検索とローカル検索に関する選択肢を含むここでのトレードオフに関する詳細なガイダンスは、このドキュメントの範囲を超えていますが、ドキュメントの将来のバージョンはそれらを範囲に導くかもしれません。
Asymmetric signature validation can be computationally expensive, and the results can also potentially vary over time (e.g., if a signing certificate is discovered to be revoked). In some cases, the user may care about the signature validation that they saw when they first read or received the message, not only about the status of the signature verification at the current time.
非対称の署名検証は計算的に高価である可能性があり、結果は時間とともに変化する可能性もあります（たとえば、署名証明書が取り消されることが発見された場合）。場合によっては、ユーザーは、現在の時刻の署名検証のステータスだけでなく、メッセージを最初に読んだり受け取ったり受け取ったときに見た署名の検証を気にすることがあります。
So, for both performance reasons and historical perspective, it may be useful for an MUA to cache signature validation results in a way that they can be easily retrieved and compared. Documenting how and when to cache signature validation, as well as how to indicate it to the user, is beyond the scope of this document, but a future version of the document may bring these topics into scope.
したがって、パフォーマンス上の理由と歴史的な観点の両方で、MUAが署名検証をキャッシュすると、簡単に取得して比較できるようにすることが役立つ場合があります。署名検証のキャッシュ方法とタイミングを文書化する方法と、ユーザーにそれを示す方法は、このドキュメントの範囲を超えていますが、ドキュメントの将来のバージョンはこれらのトピックを範囲に導入する可能性があります。
This document limits itself to consideration of the cryptographic status of single messages as a baseline concept that can be clearly and simply communicated to the user. However, some users and some MUAs may find it useful to contemplate even higher-level views of cryptographic status, which are not considered directly here.
このドキュメントは、単一のメッセージの暗号化ステータスを、ユーザーに明確かつ単に伝達できるベースラインの概念としての考慮に限定します。ただし、一部のユーザーと一部のMUAは、ここでは直接考慮されていない暗号化ステータスのより高いレベルのビューを熟考することが有用であると感じるかもしれません。
For example, a future version of the document may also consider how to indicate a simple cryptographic status of message threads (groups of explicitly related messages), conversations (groups of messages with shared sets of participants), peers, or other perspectives that an MUA can provide.
たとえば、ドキュメントの将来のバージョンでは、メッセージスレッド（明示的に関連するメッセージのグループ）、会話（参加者の共有セットを含むメッセージのグループ）、MUAが提供できる他の視点の単純な暗号化ステータスを示す方法を検討する場合があります。
As mentioned in Section 2.3, the types of security indicators displayed to the user may vary based on the expectations of the user for a given communication. At present, there is no widely shared method for the MUA to establish and maintain reasonable expectations about whether a specific rendered message should have cryptographic protections.
セクション2.3で述べたように、ユーザーに表示されるセキュリティインジケーターの種類は、特定の通信に対するユーザーの期待に基づいて異なる場合があります。現在、MUAが特定のレンダリングされたメッセージが暗号化保護を持つべきかどうかについて合理的な期待を確立および維持するための広く共有された方法はありません。
If such a standard is developed, a future version of this document should reference it and encourage the deployment of clearer and simpler security indicators.
このような標準が開発されている場合、このドキュメントの将来のバージョンはそれを参照し、より明確でよりシンプルなセキュリティインジケーターの展開を促進する必要があります。
One feature many users desire from a secure communications medium is the ability to reliably destroy a message such that it cannot be recovered even by a determined adversary. In other contexts, a similar desired property is called "forward secrecy". Doing this with standard email mechanisms such as S/MIME and PGP/MIME is challenging because of two interrelated factors:
多くのユーザーが安全な通信媒体から望む多くの機能の1つは、決定された敵によっても回復できないようにメッセージを確実に破壊する能力です。他のコンテキストでは、同様の目的のプロパティは「フォワード秘密」と呼ばれます。S/MIMEやPGP/MIMEなどの標準的な電子メールメカニズムでこれを行うことは、相互に関連する2つの要因のために困難です。
* A copy of an email message may be retained by any of the mail transport agents that handle it during delivery.
* 電子メールメッセージのコピーは、配達中にそれを処理するメール輸送エージェントのいずれかによって保持される場合があります。
* The secret key used to decrypt an encrypted email message is typically retained indefinitely.
* 暗号化された電子メールメッセージを復号化するために使用されるシークレットキーは、通常無期限に保持されます。
This means that an adversary aiming to recover the cleartext contents of a deleted message can do so by getting access to a copy of the encrypted message and the long-term secret key material.
これは、削除されたメッセージのクリアテキストの内容を回復することを目的とした敵が、暗号化されたメッセージのコピーと長期的な秘密の鍵資料にアクセスすることで、そうすることができることを意味します。
Some mitigation measures may be available to make it possible to delete some encrypted messages securely, but this document considers this use case out of scope. A future version of the document may elaborate on secure message deletion in more detail.
一部の暗号化されたメッセージを安全に削除することを可能にするためにいくつかの緩和策が利用可能になる場合がありますが、このドキュメントでは、このユースケースが範囲外であると考えています。ドキュメントの将来のバージョンは、安全なメッセージ削除について詳しく説明することができます。
This document focuses on guidance for strong, user-comprehensible end-to-end cryptographic protections for email. Other approaches are possible, including various forms of opportunistic and transport encryption, which are out of scope for this document.
このドキュメントは、電子メールの強力でユーザーが理解できるエンドツーエンドの暗号化保護のガイダンスに焦点を当てています。このドキュメントの範囲外のさまざまな形態の日和見的および輸送暗号化など、他のアプローチが可能です。
A future version of this document could describe the interaction between this guidance and more opportunistic forms of encryption, for example, some of the scenarios contemplated in [CLEARTEXT-COPY].
このドキュメントの将来のバージョンでは、このガイダンスと、[ClearText-Copy]で検討されているシナリオの一部など、より日和的な暗号化との相互作用を説明できます。
As noted in Section 7.2, the standard form for encrypted email messages is a single Cryptographic Envelope. In a scenario where multiple user agents are drafting a single encrypted message over low-bandwidth links, this can create a poor user experience, as each MUA has to retrieve the full message, including attachments, to modify the draft. Similarly, when retrieving a message with a large attachment, the receiving MUA might want to only render the Main Body Part and will have a significant delay in doing so if required to process the full message before handling.
セクション7.2に記載されているように、暗号化された電子メールメッセージの標準フォームは、単一の暗号化エンベロープです。複数のユーザーエージェントが低帯域幅リンク上で単一の暗号化されたメッセージをドラフトしているシナリオでは、各MUAが添付ファイルを含む完全なメッセージを取得してドラフトを変更する必要があるため、より低いユーザーエクスペリエンスを作成できます。同様に、大きな添付ファイルでメッセージを取得するとき、受信MUAはメインの部分のみをレンダリングしたいと思うかもしれません。
Future work might include an attempt to standardize a mechanism that eases this use case, potentially at the risk of additional metadata leakage about the message (e.g., the size and number of message parts). Any such work should explicitly try to minimize the risks and concerns described in Section 7.2.
将来の作業には、メッセージに関する追加のメタデータ漏れ（メッセージパーツのサイズと数など）のリスクがある可能性がある、このユースケースを緩和するメカニズムを標準化する試みが含まれる場合があります。そのような作業は、セクション7.2で説明されているリスクと懸念を明示的に最小限に抑えるようにする必要があります。
As noted in Section 9.7, a proxy-based implementation can be a tempting approach. But its naive form is likely to be insufficient to provide safe end-to-end encrypted email.
セクション9.7で述べたように、プロキシベースの実装は魅力的なアプローチになる可能性があります。しかし、その素朴なフォームは、安全なエンドツーエンドの暗号化された電子メールを提供するには不十分である可能性があります。
A future version of this document, or a separate but related document, could try to outline the specific additional information, state, and network API surface that would be needed to allow an MUA to be safely integrated with an encryption provider. Any such work should try to address the potential problems described in Section 9.7.
このドキュメントの将来のバージョン、または別のが関連するドキュメントは、MUAを暗号化プロバイダーと安全に統合できるようにするために必要な特定の追加情報、状態、およびネットワークAPI表面の概要を説明することができます。そのような研究は、セクション9.7で説明されている潜在的な問題に対処しようとする必要があります。
Mailing lists offer challenging complications to any notion of end-to-end cryptographic protections. By default, there is some sort of intervening MUA (see Section 9.8), but more than that, user expectations about cryptographic protections might differ from normal messages, at least insofar as they understand they are writing to a mailing list. A particular challenge to the notion of end-to-end cryptographic security with mailing lists is that a subscriber to a mailing list often does not know who else is subscribed to the mailing list. Another challenge is that, for some mailing lists, some subscribers might not have a valid, non-expired certificate.
メーリングリストは、エンドツーエンドの暗号化保護の概念に挑戦的な合併症を提供します。デフォルトでは、何らかの介在するMUAがあります（セクション9.8を参照）が、それ以上に、暗号化保護に関するユーザーの期待は、少なくともメーリングリストに書いていることを理解している限り、通常のメッセージとは異なる場合があります。メーリングリストを使用したエンドツーエンドの暗号化セキュリティの概念に対する特定の課題は、メーリングリストのサブスクライバーが他の誰がメーリングリストに購読されているかをしばしば知らないことです。もう1つの課題は、一部のメーリングリストでは、一部の加入者が有効な、expedのない証明書を持っていない可能性があることです。
Encryption can interact with mailing lists in different ways, depending on the use case of the list. It's not clear that there are any useful motivations for sending encrypted mail to a publicly archived mailing list. But an unarchived mailing list might want to provide confidentiality between all recipients, even if the recipients don't know for certain who all the other participants are. Or a mailing list with private archives might well decide that two "hops" of encryption (between the composer and the mailing list, and the mailing list and all the subscribers) are useful confidentiality measures even though they are not "end-to-end" in the sense of the composer directly to all recipients.
暗号化は、リストのユースケースに応じて、さまざまな方法でメーリングリストと対話できます。暗号化されたメールを公開されているメーリングリストに送信するための有用な動機があることは明らかではありません。しかし、退職していないメーリングリストは、他のすべての参加者が誰であるかを確実に知らない場合でも、すべての受信者間に機密性を提供したいと思うかもしれません。または、プライベートアーカイブを備えたメーリングリストは、暗号化の2つの「ホップ」（作曲家とメーリングリスト、およびメーリングリストとすべてのサブスクライバーの間）が、すべての受信者に直接「エンドツーエンド」ではない場合でも、有用な機密性の尺度であると判断する場合があります。
Similarly, cryptographic signatures may play different roles in a mailing list, depending on the list's communication goals. The mailing list itself might want to verify that an incoming message is cryptographically signed by an authorized sender before redistribution to the list subscribers. It might also want to pass along the composer's signature in a way that the subscribers can all verify it. Alternately, the mailing list might want to sign each redistributed message itself and change the message so it appears to come from the list rather than the original composer.
同様に、リストの通信目標に応じて、暗号化署名がメーリングリストで異なる役割を果たす可能性があります。メーリングリスト自体は、リストサブスクライバーに再配布する前に、承認された送信者によって着信メッセージが暗号化されていることを確認することをお勧めします。また、加入者がそれをすべて確認できるように、作曲家の署名を伝えたいと思うかもしれません。あるいは、メーリングリストは、各再配分されたメッセージ自体に署名し、メッセージを変更して、元の作曲家ではなくリストから来るように見えるかもしれません。
Yet another design for a mailing list with end-to-end cryptographic protections might involve redistributing shared secret keys to all recipients or using some sort of proxied re-encryption scheme, similar to [OPENPGP-FORWARDING].
エンドツーエンドの暗号化保護を備えたメーリングリストのさらに別のデザインには、すべての受信者に共有秘密の鍵を再配布するか、[OpenPGP-Forwarding]と同様に、何らかのプロキシ再結晶スキームを使用することが含まれます。
A future version of this document, or a separate but related document, might describe some of these trade-offs and provide guidance for safely meeting common requirements or use cases when combining end-to-end cryptographic protections with mailing lists.
このドキュメントの将来のバージョン、または別のが関連するドキュメントは、これらのトレードオフの一部を説明し、エンドツーエンドの暗号化保護とメーリングリストを組み合わせる際に、一般的な要件またはユースケースを安全に満たすためのガイダンスを提供する場合があります。
The set of constructs and recommendations in this document are derived from discussions with many different implementers, including Bjarni Rúnar Einarsson, Daniel Huigens, David Bremner, Deb Cooley, Eliot Lear, Fabian Ising, Heiko Schaefer, Holger Krekel, Jameson Rollins, John Levine, Jonathan Hammell, juga, Patrick Brunschwig, Paul Kyzivat, Pete Resnick, Roman Danyliw, Santosh Chokhani, Stephen Farrell, Thore Göbel, and Vincent Breitmoser.
The set of constructs and recommendations in this document are derived from discussions with many different implementers, including Bjarni Rúnar Einarsson, Daniel Huigens, David Bremner, Deb Cooley, Eliot Lear, Fabian Ising, Heiko Schaefer, Holger Krekel, Jameson Rollins, John Levine, Jonathan Hammell, juga, Patrick Brunschwig, Paul Kyzivat,ピート・レストニック、ローマン・ダニリウ、サントシュ・チョーカニ、スティーブン・ファレル、ソーレ・ゲーベル、ヴィンセント・ブライトモーザー。
Daniel Kahn Gillmor (editor)
American Civil Liberties Union
125 Broad St.
New York, NY 10004
United States of America
Email: dkg@fifthhorseman.net
Alexey Melnikov (editor)
Isode Ltd
14 Castle Mews
Hampton, Middlesex
TW12 2NP
United Kingdom
Email: alexey.melnikov@isode.com
Bernie Hoeneisen (editor)
pEp Project
Oberer Graben 4
CH-8400 Winterthur
Switzerland
Email: bernie@ietf.hoeneisen.ch
URI: https://pep-project.org/