[要約] RFC 8823は、End-User S/MIME証明書のためのAutomatic Certificate Management Environmentの拡張に関する規格です。このRFCの目的は、S/MIME証明書の自動管理を向上させ、エンドユーザーにより使いやすい環境を提供することです。
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 8823 Isode Ltd
Category: Informational April 2021
ISSN: 2070-1721
Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates
エンドユーザーS / MIME証明書の自動証明書管理環境への拡張
Abstract
概要
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.
このドキュメントでは、自動証明書管理環境（ACME）がS / MIMEを使用したいEメールユーザーが使用するための証明書を発行できるようにするために必要な識別子と課題を指定します。
Status of This Memo
本文書の位置付け
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/rfc8823.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8823で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
3. Use of ACME for Issuing End-User S/MIME Certificates
3.1. ACME "Challenge" Email
3.2. ACME "Response" Email
3.3. Generating Encryption-Only or Signing-Only S/MIME
Certificates
4. Internationalization Considerations
5. IANA Considerations
5.1. ACME Identifier Type
5.2. ACME Challenge Type
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Author's Address
ACME [RFC8555] is a mechanism for automating certificate management on the Internet. It enables administrative entities to prove effective control over resources like domain names, and it automates the process of generating and issuing certificates.
ACME [RFC8555]は、インターネット上の証明書管理を自動化するためのメカニズムです。これにより、管理エンティティはドメイン名のようなリソースを効果的に制御することを証明でき、証明書の生成と発行プロセスを自動化します。
This document describes an extension to ACME for use by S/MIME. Section 3 defines extensions for issuing end-user S/MIME [RFC8550] certificates.
このドキュメントでは、S / MIMEで使用するためのACMEへの拡張について説明します。セクション3エンドユーザーS / MIME [RFC8550]証明書を発行するための拡張機能を定義します。
This document aims to support both:
この文書は両方をサポートすることを目的としています。
1. A Mail User Agent (MUA) that has a built-in ACME client that is aware of the extension described in this document. (We will call such MUAs "ACME-email-aware".) Such an MUA can present a nice user interface to the user and automate certificate issuance.
1. この文書に記載されている拡張子を認識している組み込みのACMEクライアントを持つメールユーザーエージェント（MUA）。（私達はそのようなMUAS "ACME-Eメール認証"を呼び出します。）このようなMUAは、ユーザーに素敵なユーザーインターフェースを提示し、証明書発行を自動化することができます。
2. An MUA that is not ACME aware, with a separate ACME client implemented in a command-line tool or as a part of a website. While S/MIME certificate issuance is not going to be as painless as in the case of the ACME-email-aware MUA, the extra burden on a user is going to be minimal.
2. ACMEを認識していないMUAは、コマンドラインツールまたはWebサイトの一部として実装された別のACMEクライアントがあります。S / MIME証明書の発行は、ACME-Eメール認証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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
ACME [RFC8555] defines a "dns" identifier type that is used to verify that a particular entity has control over a domain or specific service associated with the domain. In order to be able to issue end-user S/MIME certificates, ACME needs a new identifier type that proves ownership of an email address.
ACME [RFC8555]は、特定のエンティティがドメインに関連付けられているドメインまたは特定のサービスを制御していることを確認するために使用される「DNS」識別子型を定義します。エンドユーザーのS / MIME証明書を発行できるようにするには、ACMEにはEメールアドレスの所有権を証明する新しい識別子タイプが必要です。
This document defines a new identifier type, "email", which corresponds to an email address. The address can be all ASCII [RFC5321] or internationalized [RFC6531]; when an internationalized email address is used, the domain part can contain both U-labels and A-labels [RFC5890]. This can be used with S/MIME or another similar service that requires possession of a certificate tied to an email address.
このドキュメントでは、Eメールアドレスに対応する新しい識別子タイプ「Eメール」を定義します。アドレスはすべてASCII [RFC5321]または国際化[RFC6531]にすることができます。国際化された電子メールアドレスを使用する場合、ドメイン部分はUラベルとA-LABELSの両方を含めることができます[RFC5890]。これは、Eメールアドレスに関連する証明書を所有する必要があるS / MIMEまたは別の同様のサービスで使用できます。
Any identifier of type "email" in a newOrder request MUST NOT have a wildcard ("*") character in its value.
新しいOrdery要求のタイプ "電子メール"の識別子は、その値にワイルドカード（ "*"）文字を持たない必要があります。
A new challenge type, "email-reply-00", is used with the "email" identifier type, which provides proof that an ACME client has control over an email address.
新しいチャレンジタイプ「email-reply-00」は、ACMEクライアントが電子メールアドレスを制御するという証明を提供する「電子メール」識別子タイプと共に使用されます。
The process of issuing an S/MIME certificate works as follows. Note that the ACME client can be a standalone application (if the MUA is not ACME-email-aware) or can be a component of the MUA.
S / MIME証明書を発行するプロセスは次のように機能します。ACMEクライアントはスタンドアロンアプリケーションである可能性があります（MUAがACME-Eメール認証ではない場合）、またはMUAのコンポーネントになる可能性があることに注意してください。
1. An end user initiates issuance of an S/MIME certificate for one of their email addresses. This might be done by using an email client UI, by running a command-line tool, by visiting a certificate authority web page, etc. This document doesn't prescribe a specific UI used to initiate S/MIME certificate issuance or where the ACME client is located.
1. エンドユーザーは、自分のEメールアドレスの1つのS / MIME証明書の発行を開始します。これは、Corment Authority Webページなどを訪問することで、コマンドラインツールを実行することによって、電子メールクライアントUIを使用して行われる可能性があります。クライアントがあります。
2. The ACME-email-aware client component begins the certificate issuance process by sending a POST request to the server's newOrder resource, including the identifier of type "email". See Section 7.4 of [RFC8555] for more details.
2. ACME-Eメールアドレスクライアントコンポーネントは、「Eメール」の型の識別子を含む、POSTリクエストをサーバの既定リソースに送信することによって証明書発行プロセスを開始します。詳細については、[RFC8555]のセクション7.4を参照してください。
3. The ACME server responds to the POST request, including an "authorizations" URL for the requested email address. The ACME client then retrieves information about the corresponding "email-reply-00" challenge, as specified in Section 7.5 of [RFC8555]. The "token" field of the corresponding challenge object (from the "challenges" array) contains token-part2. token-part2 should contain at least 128 bits of entropy. The "type" field of the challenge object is "email-reply-00". The challenge object also contains the "from" field, with the email address that would be used in the From header field of the "challenge" email message (see the next step).
3. ACMEサーバーは、要求されたEメールアドレスの「承認」URLを含むPOSTリクエストに応答します。次に、[RFC8555]のセクション7.5で指定されているように、ACMEクライアントは、対応する「email-reply-00」チャレンジに関する情報を取得します。対応するチャレンジオブジェクトの「トークン」フィールド（「課題」アレイから）には、トークンPART2が含まれています。TOKEN-PART2は少なくとも128ビットのエントロピーを含める必要があります。チャレンジオブジェクトの「Type」フィールドは "email-reply-00"です。Challengeオブジェクトには、 "from"フィールドが含まれています。 "Challenge" EメールメッセージのFrom Headerフィールドで使用される電子メールアドレスが含まれています（次のステップを参照）。
An example challenge object might look like this:
チャレンジオブジェクトの例としては、次のようになります。
{
"type": "email-reply-00",
"url": "https://example.com/acme/chall/ABprV_B7yEyA4f",
"from": "acme-challenge+2i211oi1204310@example.com",
"token": "DGyRejmCefe7v4NfDGDKfA"
}
4. After responding to the authorization request, the ACME server generates another token and a "challenge" email message with the subject "ACME: <token-part1>", where <token-part1> is the base64url-encoded [RFC4648] form of the token. The ACME server MUST generate a fresh token for each S/MIME issuance request (authorization request), and token-part1 MUST contain at least 128 bits of entropy. The "challenge" email message structure is described in more details in Section 3.1.
4. 認証要求に応答した後、ACMEサーバーは別のトークンと「ACME：<token-part1>」を使用して別のトークンと「チャレンジ」電子メールメッセージを生成します。ここで、<token-part1>はBase64URL-Encoded [RFC4648]形式です。トークン。ACMEサーバは、各S / MIME発行要求（承認要求）に対してフレッシュトークンを生成し、トークン-PART1には少なくとも128ビットのエントロピーを含める必要があります。「チャレンジ」電子メールメッセージ構造については、セクション3.1の詳細について説明しています。
5. The MUA retrieves and parses the "challenge" email message. If the MUA is ACME-email-aware, it ignores any "challenge" email that is not expected, e.g., if there is no ACME certificate issuance pending. The ACME-email-aware MUA also ignores any "challenge" email that has the Subject header field that indicates that it is an email reply, e.g., a subject starting with the reply prefix "Re:".
5. MUAは「チャレンジ」電子メールメッセージを取得して解析します。MUAがACME-Eメール認証である場合は、ACME証明書発行が保留されていない場合は、予想されない「チャレンジ」電子メールを無視します。ACME-EメールAware MUAはまた、それが電子メールの返信であることを示す件名ヘッダーフィールド、例えば返信プレフィックス "re："で始まる件名を持つ "Challenge" Eメールも無視されます。
6. The ACME client concatenates "token-part1" (received over email) and "token-part2" (received over HTTPS [RFC2818]) to create the ACME "token" and calculates keyAuthorization (as per Section 8.1 of [RFC8555]). Then, it returns the base64url-encoded SHA-256 digest [RFC6234] of the key authorization. The MUA returns the base64url-encoded SHA-256 digest obtained from the ACME client in the body of a "response" email message. The "response" email message structure is described in more details in Section 3.2. If the MUA is ACME-email-aware, it MUST NOT respond to the same "challenge" email more than once.
6. ACMEクライアントは、「Token-Part1」（電子メールで受信した）と「Token-Part2」（HTTPS [RFC2818]を介して受信）して、ACME "トークン"を作成し、keyauthorizationを計算します（[RFC8555]のセクション8.1）。その後、鍵認証のBase64URLエンコードSHA-256 Digest [RFC6234]を返します。MUAは、ACMEクライアントから取得したBase64URLエンコードSHA-256ダイジェストを「応答」電子メールメッセージの本文に返します。「応答」電子メールメッセージ構造については、3.2項で詳細に説明されています。MUAがAcme-Email-Awareの場合は、同じ「チャレンジ」電子メールに複数回応答してはいけません。
7. Once the MUA sends the "response" email, the ACME client notifies the ACME server by POST to the challenge URL ("url" field).
7. MUAが「応答」電子メールを送信すると、ACMEクライアントはACMEサーバにPOSTによってチャレンジURL（「URL」フィールド）に通知します。
8. The ACME client can start polling the authorization URL (using POST-as-GET requests) to see if the ACME server received and validated the "response" email message. (See Section 7.5.1 of [RFC8555] for more details.) If the "status" field of the challenge switches to "valid", then the ACME client can proceed with request finalization. The Certificate Signing Request (CSR) MUST indicate the exact same set of requested identifiers as the initial newOrder request. For an identifier of type "email", the PKCS#10 [RFC2986] CSR MUST contain the requested email address in an extensionRequest attribute [RFC2985] requesting a subjectAltName extension. The email address MUST also match the From header field value of the "response" email message.
8. ACMEクライアントは、ACMEサーバが受信され、「応答」電子メールメッセージを受信して検証したかどうかを確認するために、許可URLのポーリング（Post AS-GET要求を使用）を開始できます。（詳細については、[RFC8555のセクション7.5.1を参照）チャレンジの「ステータス」フィールドが「有効」に切り替わると、ACMEクライアントはリクエストファイナライズを続行できます。証明書署名要求（CSR）は、最初のNeworderリクエストとして要求された識別子のセットを正確に示す必要があります。「電子メール」の識別子の場合、PKCS＃10 [RFC2986] CSRには、ExtensionRequest属性[RFC2985]の要求された電子メールアドレスが、[jabjectalTName拡張子]を要求している必要があります。電子メールアドレスは、「応答」電子メールメッセージのFromヘッダーフィールド値も一致している必要があります。
9. In order to request generation of signing-only or encryption-only S/MIME certificates (as opposed to requesting generation of S/MIME certificates suitable for both), the CSR needs to include the key usage extension (see Section 4.4.2 of [RFC8550]). This is described in more details in Section 3.3.
9. （両方に適したS / MIME証明書の生成とは対照的に）署名専用のS / MIME証明書の生成を要求するために、CSRは鍵使用量拡張を含める必要があります（[4.4.2項を参照）。RFC8550]）。これについては、3.3項で詳細に説明されています。
10. If a request to finalize an order is successful, the ACME server will return a 200 (OK) with an updated order object. If the certificate is issued successfully, i.e., if the order "status" is "valid", then the ACME client can download the issued S/MIME certificate from the URL specified in the "certificate" field.
10. 注文を確定する要求が成功した場合、ACMEサーバーは更新された順序オブジェクトを使用して200（OK）を返します。証明書が正常に発行された場合、すなわち注文「ステータス」が「有効」である場合、ACMEクライアントは、「証明書」フィールドで指定されたURLから発行されたS / MIME証明書をダウンロードすることができる。
A "challenge" email message MUST have the following structure:
「チャレンジ」電子メールメッセージには、次のような構造が必要です。
1. The Subject header field has the following syntax: "ACME: <token-part1>", where the prefix "ACME:" is followed by folding white space (FWS; see [RFC5322]) and then by <token-part1>, which is the base64url-encoded first part of the ACME token that MUST be at least 128 bits long after decoding. Due to the recommended 78-octet line-length limit in [RFC5322], the subject line can be folded, so white spaces (if any) within the <token-part1> MUST be ignored. [RFC2231] encoding of the Subject header field MUST be supported, and, when used, only the "UTF-8" and "US-ASCII" charsets are allowed; other charsets MUST NOT be used. The US-ASCII charset SHOULD be used.
1. [件名ヘッダ]フィールドには、次の構文があります。 "ACME：<token-part1>"の後に、プレフィックス "ACME："の後に折りたたみホワイトスペース（FWS; [RFC5322]）、次に<token-part1>を参照してください。復号化後の長さは少なくとも128ビットでなければならないACMEトークンのBase64URLエンコードされた最初の部分です。[RFC5322]では、推奨される78オクテット線長制限により、件名を折りたたんでいるため、<token-part1>内の空白スペース（もしあれば）は無視されなければなりません。[RFC2231]サブジェクトヘッダーフィールドのエンコーディングはサポートされている必要がありますが、使用時は "UTF-8"と "US-ASCII"チャレセットのみが許可されています。他のチャーセットは使用してはいけません。US-ASCII文字セットを使用する必要があります。
2. The From header field MUST be the same email address as specified in the "from" field of the challenge object.
2. From Headerフィールドは、チャレンジオブジェクトの「From」フィールドに指定されているものと同じ電子メールアドレスでなければなりません。
3. The To header field MUST be the email address of the entity that requested the S/MIME certificate to be generated.
3. TOヘッダーフィールドは、生成されるS / MIME証明書を要求したエンティティの電子メールアドレスでなければなりません。
4. The message MAY contain a Reply-To and/or CC header field.
4. メッセージには、返信先および/またはCCヘッダフィールドが含まれていてもよい。
5. The message MUST include the Auto-Submitted header field with the value "auto-generated" [RFC3834]. To aid in debugging (and, for some implementations, to make automated processing easier), the Auto-Submitted header field SHOULD include the "type=acme" parameter. It MAY include other optional parameters, as allowed by the syntax of the Auto-Submitted header field.
5. メッセージには、「自動生成された」[RFC3834]の値を持つ自動送信ヘッダーフィールドを含める必要があります。デバッグを支援する（そして、いくつかの実装で自動処理を容易にするために）、[自動送信ヘッダ]フィールドには、「Type = ACME」パラメータを含める必要があります。自動送信されたヘッダーフィールドの構文によって許可されるように、他のオプションのパラメータを含めることができます。
6. In order to prove authenticity of a challenge message, it MUST be signed using either DomainKeys Identified Mail (DKIM) [RFC6376] or S/MIME [RFC8551].
6. チャレンジメッセージの信頼性を証明するためには、DomainKeys Inventified Mail（DKIM）[RFC6376]またはS / MIME [RFC8551]のいずれかを使用して署名する必要があります。
* If DKIM signing is used, the resulting DKIM-Signature header field MUST contain the "h=" tag that includes at least the From, Sender, Reply-To, To, CC, Subject, Date, In-Reply-To, References, Message-ID, Auto-Submitted, Content-Type, and Content-Transfer-Encoding header fields. The DKIM-Signature header field's "h=" tag SHOULD also include the Resent-Date, Resent-From, Resent-To, Resent-Cc, List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive, and List-Unsubscribe-Post header fields. The domain from the "d=" tag of the DKIM-Signature header field MUST be the same as the domain from the From header field of the "challenge" email.
* DKIM署名が使用されている場合、結果のDKIM-Signature Headerフィールドには、少なくともFROM、Sender、Reply-to、To、CC、サブジェクト、日付、in-reply-to-fraintes、参照、 "H ="タグが含まれていなければなりません。メッセージID、自動送信、コンテンツタイプ、およびコンテンツ転送エンコーディングヘッダフィールド。DKIMシグニチャヘッダフィールドの「h =」タグには、RESENT-DATE、RESENT-FROM、RESENT-TO-RESENT-CC、LIST-ID、リストヘルプ、List-unsubscribe、list-subscribe、list-postも含める必要があります。、List-Owner、List-Archive、およびList-unsubscribe-postヘッダーフィールド。Dkim-Signature Headerフィールドの "d ="タグのドメインは、 "Challenge" EメールのFrom Headerフィールドのドメインと同じでなければなりません。
* If S/MIME signing is used, the certificate corresponding to the signer MUST have an rfc822Name subjectAltName extension with the value equal to the From header field email address of the "challenge" email.
* S / MIME署名が使用されている場合、署名者に対応する証明書には、[Challenge]電子メールの[From Header]フィールドの電子メールアドレスに等しい値を持つRFC822NAME SubjectLatName拡張子が必要です。
7. The body of the challenge message is not used for automated processing, so it can be any media type. (However, there are extra requirements on S/MIME signing, if used. See below.) Typically, it is text/plain or text/html containing a human-readable explanation of the purpose of the message. If S/MIME signing is used to prove authenticity of the challenge message, then the multipart/signed or "application/pkcs7-mime; smime-type=signed-data;" media type should be used. Either way, it MUST use S/MIME header protection.
7. チャレンジメッセージの本文は自動処理には使用されないので、どのメディアタイプにすることもできます。（ただし、S / MIME署名には追加の要件があります。下記参照）通常、メッセージの目的の人間が読める説明を含むテキスト/平文またはテキスト/ HTMLです。S / MIME署名が、チャレンジメッセージの信頼性を証明するために使用される場合、マルチパート/符号付きまたは「アプリケーション/ PKCS7-MIME; smime-type =署名 - データ」。メディアタイプを使用する必要があります。どちらの方法でも、S / MIMEヘッダー保護を使用する必要があります。
An email client compliant with this specification that detects that a particular "challenge" email fails the validation described above MUST ignore the challenge and thus will not generate a "response" email. To aid in debugging, such failed validations SHOULD be logged.
特定の「チャレンジ」電子メールが失敗したことを検出するこの仕様に準拠した電子メールクライアントは、上記の検証を無視しなければならず、したがって「応答」電子メールを生成することはできません。デバッグを支援するには、このような失敗した検証を記録する必要があります。
Here is an example of an ACME "challenge" email (note that, for simplicity, DKIM-related header fields are not included).
ACMEの「チャレンジ」電子メールの例は次のとおりです（簡単にするために、DKIM関連のヘッダーフィールドは含まれていません）。
Auto-Submitted: auto-generated; type=acme
Date: Sat, 5 Dec 2020 10:08:55 +0100
Message-ID: <A2299BB.FF7788@example.org>
From: acme-generator@example.org
To: alexey@example.com
Subject: ACME: LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=
Content-Type: text/plain
MIME-Version: 1.0
This is an automatically generated ACME challenge for email address "alexey@example.com". If you haven't requested an S/MIME certificate generation for this email address, be very afraid. If you did request it, your email client might be able to process this request automatically, or you might have to paste the first token part into an external program.
これは、Eメールアドレス "alexey@example.com"に自動的に生成されたACMEチャレンジです。このメールアドレスのS / MIME証明書の生成を要求していない場合は、非常に恐れてください。あなたがそれを要求したならば、あなたの電子メールクライアントはこの要求を自動的に処理することができ、あるいは最初のトークン部分を外部プログラムに貼り付ける必要があるかもしれません。
Figure 1
図1
A valid "response" email message MUST have the following structure:
有効な「応答」電子メールメッセージには、次のような構造が必要です。
1. The Subject header field is formed as a reply to the ACME "challenge" email (see Section 3.1). Its syntax is the same as that of the challenge message except that it may be prefixed by a US-ASCII reply prefix (typically "Re:") and FWS (see [RFC5322]), as is normal in reply messages. When parsing the subject, ACME servers MUST decode [RFC2231] encoding (if any), and then they can ignore any prefix before the "ACME:" label.
1. サブジェクトヘッダーフィールドは、ACMEの「チャレンジ」電子メールへの返信として形成されます（セクション3.1を参照）。その構文は、Replyメッセージで通常のように、US-ASCII応答プレフィックス（通常は "RE："）とFWS（ "RFC5322]を参照）に接頭辞されることがあることを除けば、チャレンジメッセージのそれと同じです。件名を解析するとき、ACMEサーバーは[RFC2231]エンコーディング（任意の場合）をデコードする必要があります。その後、「ACME：」ラベルの前にプレフィックスを無視できます。
2. The From header field contains the email address of the user that is requesting S/MIME certificate issuance.
2. [From Header]フィールドには、S / MIME証明書の発行を要求しているユーザーのEメールアドレスが含まれています。
3. The To header field of the response contains the value from the Reply-To header field from the challenge message (if set). Otherwise, it contains the value from the From header field of the challenge message.
3. 応答のTO Headerフィールドには、チャレンジメッセージ（設定されている場合）からのReply-toヘッダーフィールドからの値が含まれています。それ以外の場合は、チャレンジメッセージのFromヘッダーフィールドからの値が含まれています。
4. The Cc header field is ignored if present in the "response" email message.
4. 「応答」電子メールメッセージに存在する場合、CCヘッダーフィールドは無視されます。
5. The In-Reply-To header field SHOULD be set to the Message-ID header field of the challenge message according to rules in Section 3.6.4 of [RFC5322].
5. [RFC5322]のセクション3.6.4の規則に従って、[Reply-To Header]フィールドをチャレンジメッセージのMessage-IDヘッダーフィールドに設定する必要があります。
6. List-* header fields [RFC4021][RFC8058] MUST be absent (i.e., the reply can't come from a mailing list).
6. list- *ヘッダーフィールド[RFC4021] [RFC8058]はありません（すなわち、返信はメーリングリストから来ることはできません）。
7. The media type of the "response" email message is either text/ plain or multipart/alternative [RFC2046], containing text/plain as one of the alternatives. (Note that the requirement to support multipart/alternative is to allow use of ACME-unaware MUAs, which can't always generate pure text/plain, e.g., if they reply to a text/html). The text/plain body part (whether or not it is inside multipart/alternative) MUST contain a block of lines starting with the line "-----BEGIN ACME RESPONSE-----", followed by one or more lines containing the base64url-encoded SHA-256 digest [RFC6234] of the key authorization, calculated from concatenated token-part1 (received over email) and token-part2 (received over HTTPS), as outlined in the 5th bullet in Section 3. (Note that each line of text/plain is terminated by CRLF. Bare LFs or bare CRs are not allowed.) Due to historical line-length limitations in email, line endings (CRLFs) can be freely inserted in the middle of the encoded digest, so they MUST be ignored when processing it. The final line of the encoded digest is followed by a line containing:
7. 「応答」電子メールメッセージのメディアタイプは、テキスト/プレーンまたはマルチパート/代替[RFC2046]で、選択肢の1つとしてテキスト/プレーンを含みます。 （マルチパート/代替案をサポートする要件は、acme-naware muasを使用できるようにすることです。テキスト/プレーンボディ部分（マルチパート/オプティマルパート内にあるかどうか）は、 "-----始まるACME応答-----"の後に続いて1つ以上の行を含む行のブロックを含める必要があります。セクション3の5番目の箇条書きで概説されているように、連結されたトークン-PORT1（Eメールで受信した）とトークン（HTTPSを介した）から計算された、鍵認証のBase64URLエンコードSHA-256 Digest [RFC6234]。テキスト/平野の各行はCRLFによって終了します。Bare LFSまたはBare CRSは許可されていません。）Eメールの歴史的な線長の制限により、ラインエンディング（CRLFS）は符号化されたダイジェストの途中で自由に挿入することができるので、処理するときは無視する必要があります。エンコードされたダイジェストの最後の行の後に、次のような行が続きます。
-----END ACME RESPONSE-----
Any text before and after this block is ignored. For example, such text might explain what to do with it for ACME-unaware clients.
このブロックの前後のテキストは無視されます。たとえば、そのようなテキストでは、Acme-Unawareクライアント用に何をすべきかを説明するかもしれません。
8. There is no need to use any Content-Transfer-Encoding other than 7bit for the text/plain body part. Use of quoted-printable or base64 in a "response" email message is not necessary and should be avoided, though it is permitted.
8. テキスト/プレーンボディ部分の7ビット以外のコンテンツ転送エンコーディングを使用する必要はありません。「応答」電子メールメッセージで引用符付き印刷可能またはBase64の使用は必要ではなく、許可されていますが、避けるべきです。
9. In order to prove authenticity of a response message, it MUST be DKIM [RFC6376] signed. The resulting DKIM-Signature header field MUST contain the "h=" tag that includes at least the From, Sender, Reply-To, To, CC, Subject, Date, In-Reply-To, References, Message-ID, Content-Type, and Content-Transfer-Encoding header fields. The DKIM-Signature header field's "h=" tag SHOULD also include the Resent-Date, Resent-From, Resent-To, Resent-Cc, List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive, and List-Unsubscribe-Post header fields. The domain from the "d=" tag of DKIM-Signature header field MUST be the same as the domain from the From header field of the "response" email.
9. 応答メッセージの信頼性を証明するためには、DKIM [RFC6376]署名されている必要があります。結果のDkim-Signature Headerフィールドには、少なくともFROM、Sender、Reply-to、To、CC、サブジェクト、日付、in-in-in-to、参照、メッセージID、Content-を含む "H ="タグが含まれていなければなりません。型、およびコンテンツ転送エンコーディングヘッダーフィールドDKIMシグニチャヘッダフィールドの「h =」タグには、RESENT-DATE、RESENT-FROM、RESENT-TO-RESENT-CC、LIST-ID、リストヘルプ、List-unsubscribe、list-subscribe、list-postも含める必要があります。、List-Owner、List-Archive、およびList-unsubscribe-postヘッダーフィールド。Dkim-Signature Headerフィールドの "d ="タグからのドメインは、 "応答"電子メールのfromヘッダーフィールドのドメインと同じでなければなりません。
Here is an example of an ACME "response" email (note that, for simplicity, DKIM-related header fields are not included).
ACMEの「応答」電子メールの例は次のとおりです（簡単にするために、DKIM関連のヘッダーフィールドは含まれていません）。
Date: Sat, 5 Dec 2020 12:01:45 +0100
Message-ID: <111-22222-3333333@example.com>
In-Reply-To: <A2299BB.FF7788@example.org>
From: alexey@example.com
To: acme-generator@example.org
Subject: Re: ACME: LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=
Content-Type: text/plain
MIME-Version: 1.0
-----BEGIN ACME RESPONSE-----
LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy
jxAjEuX0=
-----END ACME RESPONSE-----
Figure 2
図2.
ACME extensions specified in this document can be used to request signing-only or encryption-only S/MIME certificates.
このドキュメントで指定されているACME拡張機能は、署名専用または暗号化のみのS / MIME証明書を要求するために使用できます。
In order to request signing-only S/MIME certificates, the CSR MUST include the key usage extension with digitalSignature and/or nonRepudiation bits set and no other bits set.
署名専用のS / MIME証明書を要求するために、CSRには、DigitalSignatureおよび/または非微妙なビットセットと他のビットが設定されていないキー使用量拡張子を含める必要があります。
In order to request encryption-only S/MIME certificates, the CSR MUST include the key usage extension with keyEncipherment or keyAgreement bits set and no other bits set.
暗号化のみのS / MIME証明書を要求するために、CSRには、キー暗号化ビットまたはkeyagreementビットセットと他のビットが設定されていないキー使用法拡張子を含める必要があります。
Presence of both of the above sets of key usage bits in the CSR, as well as absence of the key usage extension in the CSR, signals to the ACME server to issue an S/MIME certificate suitable for both signing and encryption.
CSRの上記の鍵使用率ビットのセットのセットの存在、およびCSRでの鍵使用量拡張が存在しないと、署名と暗号化の両方に適したS / MIME証明書を発行するためのACMEサーバーへの信号。
[RFC8616] updated/clarified use of DKIM with internationalized email addresses [RFC6531]. Please consult [RFC8616] in regards to any changes that need to be implemented.
[RFC8616]国際化されたEメールアドレス[RFC6531]を使用したDKIMの使用/明確化された使用。実装する必要がある変更に関して[RFC8616]に相談してください。
Use of non-ASCII characters in left-hand sides of internationalized email addresses requires putting internationalized email addresses in X.509 certificates [RFC8398].
国際化された電子メールアドレスの左側のASCII文字以外の文字の使用は、X.509証明書[RFC8398]に国際化された電子メールアドレスを入れる必要があります。
IANA has registered a new identifier type in the "ACME Identifier Types" registry defined in Section 9.7.7 of [RFC8555] with Label "email" and a Reference to this document, [RFC5321], and [RFC6531]. The new identifier type corresponds to an (all ASCII) email address [RFC5321] or internationalized email addresses [RFC6531].
IANAは、「RFC8555」の「ACME識別子型」レジストリに、[RFC5321]、[RFC6531]、[RFC8555]の「ACME識別子型」レジストリに登録しました。新しい識別子タイプは、（すべてのASCII）電子メールアドレス[RFC5321]または国際化された電子メールアドレス[RFC6531]に対応しています。
IANA has registered a new entry in the "ACME Validation Methods" registry defined in Section 9.7.8 of [RFC8555]. This entry is as follows:
IANAは、[RFC8555]のセクション9.7.8で定義されている「ACME検証メソッド」レジストリに新しいエントリを登録しました。このエントリは次のとおりです。
+================+=================+======+===========+
| Label | Identifier Type | ACME | Reference |
+================+=================+======+===========+
| email-reply-00 | email | Y | RFC 8823 |
+----------------+-----------------+------+-----------+
Table 1
表1
Please see the Security Considerations section of [RFC8555] for general security considerations related to the use of ACME. This challenge/response protocol demonstrates that an entity that controls the private key (corresponding to the public key in the certificate) also controls the named email account. The ACME server is confirming that the requested email address belongs to the entity that requested the certificate, but this makes no claim to address correctness or fitness for purpose. If such claims are needed, they must be obtained by some other mechanism.
ACMEの使用に関連する一般的なセキュリティ上の考慮事項については、[RFC8555]の[セキュリティ上の考慮事項]セクションを参照してください。このチャレンジ/レスポンスプロトコルは、（証明書の公開鍵に対応する）秘密鍵を制御するエンティティも、名前付き電子メールアカウントを制御することを示しています。ACMEサーバーは、要求されたEメールアドレスが証明書を要求したエンティティに属していることを確認していますが、これは目的の正当性や適合性に対処することを主張しません。そのような請求が必要な場合は、他のメカニズムによって得る必要があります。
The security of the "email-reply-00" challenge type depends on the security of the email system. A third party that can read and reply to user's email messages (by possessing a user's password or a secret derived from it that can give read and reply access, such as "password equivalent" information, or by being given permissions to act on a user's behalf using email delegation features common in some email systems) can request S/MIME certificates using the protocol specified in this document and is indistinguishable from the email account owner. This has several possible implications:
「email-reply-00」チャレンジタイプのセキュリティは、電子メールシステムのセキュリティによって異なります。ユーザーの電子メールメッセージに読み書きすることができる第三者（ユーザーのパスワードまたはそれから派生する秘密を持つことによって、「パスワードと同等の」情報などの読み取りおよび返信アクセスを与えることができ、またはユーザーのユーザーに行動する権限を与えることができる。電子メールの委任機能を使用して、一部の電子メールシステムで共通の特徴を使用することは、このドキュメントで指定されたプロトコルを使用してS / MIME証明書を要求することができ、電子メールアカウントの所有者と区別がつかない。これにはいくつかの可能な意味があります。
1. An entity that compromised an email account would be able to request S/MIME certificates using the protocol specified in this document, and such entity couldn't be distinguished from the legitimate email account owner (unless some external sources of information are consulted).
1. 電子メールアカウントを危険にさらすエンティティは、このドキュメントで指定されたプロトコルを使用してS / MIME証明書を要求することができ、そのようなエンティティは正当な電子メールアカウントの所有者とは区別できませんでした（一部の外部情報源は相談されていない限り）。
2. For email addresses with legitimate shared access/control by multiple users, any such user would be able to request S/MIME certificates using the protocol specified in this document; such requests can't be attributed to a specific user without consulting external systems (such as IMAP/SMTP access logs).
2. 複数のユーザによる正当な共有アクセス/制御を有する電子メールアドレスの場合、この文書で指定されたプロトコルを使用してS / MIME証明書を要求することができます。そのような要求は、外部システム（IMAP / SMTPアクセスログなど）を参照せずに特定のユーザーに起因することはできません。
3. The protocol specified in this document is not suitable for use with email addresses associated with mailing lists [RFC5321]. While it is not always possible to guarantee that a particular S/ MIME certificate request is not from a mailing list address, prohibition on inclusion of List-* header fields helps certificate issuers to handle most common cases.
3. このドキュメントで指定されているプロトコルは、メーリングリスト[RFC5321]に関連付けられている電子メールアドレスでの使用には適していません。特定のS / MIME証明書要求がメーリングリストのアドレスからではないことを常に可能ではないが、List- *ヘッダフィールドを含める禁止は、証明書発行者が最も一般的なケースを処理するのに役立ちます。
An email system in its turn depends on DNS. A third party that can manipulate DNS MX records for a domain might be able to redirect an email and can get (at least temporary) read and reply access to it. Similar considerations apply to DKIM TXT records in DNS. Use of DNSSEC by email system administrators is recommended to avoid making it easy to spoof DNS records affecting an email system. However, use of DNSSEC is not ubiquitous at the time of publishing of this document, so it is not required here. Also, many existing systems that rely on verification of ownership of an email address -- for example, 2-factor authentication systems used by banks or traditional certificate issuance systems -- send email messages to email addresses, expecting the owner to click on the link supplied in them (or to reply to a message), without requiring use of DNSSEC. So the risk of not requiring DNSSEC is presumed acceptable in this document.
ターンの電子メールシステムはDNSによって異なります。ドメインのDNS MXレコードを操作できるサードパーティは、電子メールをリダイレクトでき、（少なくとも一時的な）読み取りと返信アクセスを取得できます。DNSのDKIM TXTレコードにも同様の考慮事項が適用されます。電子メールシステム管理者によるDNSSECの使用は、電子メールシステムに影響を与えるDNSレコードを偽装しやすくすることを推奨します。ただし、この文書の発行時にはDNSSECの使用は普遍的ではないので、ここでは必要ありません。また、電子メールアドレスの所有権の検証に依存する多くの既存のシステム - 例えば、銀行や伝統的な証明書発行システムで使用される2要素認証システム - 電子メールアドレスに電子メールメッセージを送信し、所有者がリンクをクリックすることを期待してDNSSECを使用することなく、それらの中で提供されている（またはメッセージに返信するために）。したがって、DNSSECを必要としないリスクは、この文書では許容できると推定されます。
An ACME email challenge message can be forged by an attacker. As per requirements on an ACME-email-aware MUA specified in Section 3, the MUA will not respond to requests it is not expecting. Even if the attacker causes the erroneous "response" email to go to an attacker-controlled email address, very little information is leaked -- the SHA-256 hash of the key authorization would be leaked, not the key authorization itself, so no parts of the token or the account key thumbprint are leaked.
ACMEの電子メールチャレンジメッセージは、攻撃者によって偽造できます。セクション3で指定されたACME-Eメール対策MUAの要件に従って、MUAは期待されていない要求に応答しません。攻撃者が誤った「応答」電子メールを攻撃者管理された電子メールアドレスに行わせたとしても、非常に少ない情報が漏洩します。鍵認証のSHA-256ハッシュは漏洩します。トークンまたはアカウントキーのサムプリントの漏洩が漏洩します。
An attacker that can read the "response" email has only one chance to guess the token-part2. Even if the attacker can guess it right, it still needs to know the ACME account key to be able to make use of the intercepted SHA-256 hash of the key authorization.
「応答」電子メールを読むことができる攻撃者には、トークンパート2を推測する機会が1つしかありません。攻撃者がそれを正しく推測できる場合でも、鍵承認の傍受されたSHA-256ハッシュを利用できるようにACMEアカウントキーを知る必要があります。
Also see the Security Considerations section of [RFC6376] for details on how DKIM depends on the DNS and the respective vulnerabilities this dependence has.
DKIMがこの依存関係にあるDNSとそれぞれの脆弱性にどのように依存するかについての詳細については、[RFC6376]のセキュリティ上の考慮事項のセクションも参照してください。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N.およびN.Borenstein、「MultiPurpose Internet Mail Extensions（MIME）パート2：メディアタイプ」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<https：//www.rfc-editor.org/ info / rfc2046>。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, <https://www.rfc-editor.org/info/rfc2231>.
[RFC2231] Freed、N.およびK.Moore、「MIMEパラメータ値とエンコードワード拡張：文字セット、言語、および継続」、RFC 2231、DOI 10.17487 / RFC2231、1997年11月、<https：//www.rfc-Editor.org/info/rfc2231>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] RESCORLA、E.、「HTTP over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https：//www.rfc-editor.org/info/rfc2818>。
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000, <https://www.rfc-editor.org/info/rfc2985>.
[RFC2985] Nystrom、M.およびB. Kaliski、 "PKCS＃9：選択オブジェクトクラスおよび属性タイプバージョン2.0"、RFC 2985、DOI 10.17487 / RFC2985、2000年11月、<https://www.rfc-editor.org/ info / rfc2985>。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/info/rfc2986>.
[RFC2986] NYSTROM、M.およびB.Kaliski、「PKCS＃10：認証依頼版仕様バージョン1.7」、RFC 2986、DOI 10.17487 / RFC2986、2000年11月、<https：//www.rfc-editor.org/info/ RFC2986>。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, DOI 10.17487/RFC3834, August 2004, <https://www.rfc-editor.org/info/rfc3834>.
[RFC3834]ムーア、K。、「電子メールへの自動応答のための推奨事項」、RFC 3834、DOI 10.17487 / RFC3834、2004年8月、<https：//www.rfc-editor.org/info/rfc3834>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https：//www.rfc-editor.org/info/rfc4648>。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC5321] Klensin、J.、「シンプルメール転送プロトコル」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<https：//www.rfc-editor.org/info/rfc5321>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P.、Ed。、「インターネットメッセージフォーマット」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https：//www.rfc-editor.org/info/rfc5322>。
[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>.
[RFC5890] Klensin、J.、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<https：//www.rfc-editor.org/info/RFC5890>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234]イーストレイク3RD、D.およびT.Hansen、「米国セキュアハッシュアルゴリズム（SHAおよびSHAベースのHMACおよびHKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：///www.rfc-editor.org/info/rfc6234>。
[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>.
[RFC6376] Crocker、D.、ED。、Hansen、T.、Ed。、およびM.Kucherawy、Ed。、「ドメインキー識別メール（DKIM）シグニチャ」、STD 76、RFC 6376、DOI 10.17487 / RFC6376、2011年9月<https：//www.rfc-editor.org/info/rfc6376>。
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, <https://www.rfc-editor.org/info/rfc6531>.
[RFC6531] YAO、J.およびW. MAO、「国際化された電子メールのためのSMTP拡張」、RFC 6531、DOI 10.17487 / RFC6531、2012年2月、<https://www.rfc-editor.org/info/rfc6531>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized Email Addresses in X.509 Certificates", RFC 8398, DOI 10.17487/RFC8398, May 2018, <https://www.rfc-editor.org/info/rfc8398>.
[RFC8398]メルニコフ、A.、ED。W. Chuang、Ed。、「証明書の国際化された電子メールアドレス」、RFC 8398、DOI 10.17487 / RFC8398、2018年5月、<https：//www.rfc-editor.org/info/rfc8398>。
[RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550, April 2019, <https://www.rfc-editor.org/info/rfc8550>.
[RFC8550] Schaad、J.、Ramsdell、B.、およびS。ターナー、「Secure / Multipurpose Internet Mail Extensions（S / MIME）バージョン4.0証明書処理」、RFC 8550、DOI 10.17487 / RFC8550、2019年4月、<https：//www.rfc-editor.org/info/rfc8550>。
[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>.
[RFC8551] Schaad、J.、Ramsdell、B.、およびS。ターナー、「セキュア/多目的インターネットメール拡張（S / MIME /多目的インターネットメール拡張」、RFC 8551、DOI 10.17487 / RFC8551、2019年4月、<https：//www.rfc-editor.org/info/rfc8551>。
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.
[RFC8555] Barnes、R.、Hoffman-Andrews、J.、McCarney、D.、およびJ.Kasten、「自動証明書管理環境（ACME）」、RFC 8555、DOI 10.17487 / RFC8555、2019年3月、<https：//www.rfc-editor.org/info/rfc8555>。
[RFC8616] Levine, J., "Email Authentication for Internationalized Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019, <https://www.rfc-editor.org/info/rfc8616>.
[RFC8616] Levine、J.、「国際化メールの電子メール認証」、RFC 8616、DOI 10.17487 / RFC8616、2019年6月、<https：//www.rfc-editor.org/info/rfc8616>。
[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, DOI 10.17487/RFC4021, March 2005, <https://www.rfc-editor.org/info/rfc4021>.
[RFC4021] Klyne、G.およびJ.Palme、「メールとMIMEヘッダーフィールドの登録」、RFC 4021、DOI 10.17487 / RFC4021、2005年3月、<https：//www.rfc-editor.org/info/rfc4021>。
[RFC8058] Levine, J. and T. Herkula, "Signaling One-Click Functionality for List Email Headers", RFC 8058, DOI 10.17487/RFC8058, January 2017, <https://www.rfc-editor.org/info/rfc8058>.
[RFC8058] Levine、J.およびT.Herkula、「リストメールヘッダーのシグナリングワンクリック機能」、RFC 8058、DOI 10.17487 / RFC8058、2017年1月、<https：//www.rfc-editor.org/info/RFC8058>。
Acknowledgements
謝辞
Thank you to Andreas Schulze, Gerd v. Egidy, James A. Baker, Ben Schwartz, Peter Yee, Hilarie Orman, Michael Jenkins, Barry Leiba, Fraser Tweedale, Daniel Kahn Gillmor, and Benjamin Kaduk for their suggestions, comments, and corrections of this document.
Andreas Schulze、Gerd v。Egidy、James A. Baker、Ben Schwartz、Peter Yee、Hilarie Orman、Michael Jenkins、Barry Leiba、Fraser Tweedale、Daniel Kahn Gillmor、およびBenjamin Kadukの提案、コメント、および修正このドキュメント。
Author's Address
著者の住所
Alexey Melnikov Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
Alexey Melnikov Isode Ltd 14 Castle Mews Hampton、ミドルセックスTW12 2NPイギリス
Email: alexey.melnikov@isode.com