[要約] RFC 8398は、X.509証明書で国際化されたメールアドレスをサポートするための仕様です。その目的は、国際的なユーザーに対して、メールアドレスを正確に表現するための標準化を提供することです。
Internet Engineering Task Force (IETF) A. Melnikov, Ed.
Request for Comments: 8398 Isode Ltd
Updates: 5280 W. Chuang, Ed.
Category: Standards Track Google, Inc.
ISSN: 2070-1721 May 2018
Internationalized Email Addresses in X.509 Certificates
X.509証明書の国際化された電子メールアドレス
Abstract
概要
This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address.
このドキュメントでは、X.509サブジェクト代替名および発行者代替名拡張のotherNameフィールドに含める新しい名前フォームを定義します。これにより、証明書サブジェクトを国際化された電子メールアドレスに関連付けることができます。
This document updates RFC 5280.
このドキュメントはRFC 5280を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8398.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8398で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. Name Definitions . . . . . . . . . . . . . . . . . . . . . . 3
4. IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Matching of Internationalized Email Addresses in X.509
Certificates . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Name Constraints in Path Validation . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Example of SmtpUTF8Mailbox . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
[RFC5280] defines the rfc822Name subjectAltName name type for representing email addresses as described in [RFC5321]. The syntax of rfc822Name is restricted to a subset of US-ASCII characters and thus can't be used to represent internationalized email addresses [RFC6531]. This document defines a new otherName variant to represent internationalized email addresses. In addition this document requires all email address domains in X.509 certificates to conform to IDNA2008 [RFC5890].
[RFC5280]は、[RFC5321]で説明されているように、電子メールアドレスを表すためのrfc822Name subjectAltName名前タイプを定義します。 rfc822Nameの構文はUS-ASCII文字のサブセットに制限されているため、国際化された電子メールアドレス[RFC6531]を表すために使用することはできません。このドキュメントでは、国際化された電子メールアドレスを表す新しいotherNameバリアントを定義します。さらに、このドキュメントでは、X.509証明書のすべての電子メールアドレスドメインがIDNA2008 [RFC5890]に準拠している必要があります。
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]で説明されているように解釈されます。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation.
正式な構文は、拡張バッカスナウアフォーム（ABNF）[RFC5234]表記を使用します。
The GeneralName structure is defined in [RFC5280] and supports many different name forms including otherName for extensibility. This section specifies the SmtpUTF8Mailbox name form of otherName so that internationalized email addresses can appear in the subjectAltName of a certificate, the issuerAltName of a certificate, or anywhere else that GeneralName is used.
GeneralName構造は[RFC5280]で定義されており、拡張性のためにotherNameを含む多くの異なる名前形式をサポートしています。このセクションでは、otherNameのSmtpUTF8Mailbox名の形式を指定して、国際化された電子メールアドレスを証明書のsubjectAltName、証明書のissuerAltName、またはGeneralNameが使用される他の場所に表示できるようにします。
id-on-SmtpUTF8Mailbox OBJECT IDENTIFIER ::= { id-on 9 }
SmtpUTF8Mailbox ::= UTF8String (SIZE (1..MAX))
-- SmtpUTF8Mailbox conforms to Mailbox as specified
-- in Section 3.3 of RFC 6531.
When the subjectAltName (or issuerAltName) extension contains an internationalized email address with a non-ASCII local-part, the address MUST be stored in the SmtpUTF8Mailbox name form of otherName. The format of SmtpUTF8Mailbox is defined as the ABNF rule SmtpUTF8Mailbox. SmtpUTF8Mailbox is a modified version of the internationalized Mailbox that was defined in Section 3.3 of [RFC6531], which was derived from Mailbox as defined in Section 4.1.2 of [RFC5321]. [RFC6531] defines the following ABNF rules for Mailbox whose parts are modified for internationalization: <Local-part>, <Dot-string>, <Quoted-string>, <QcontentSMTP>, <Domain>, and <Atom>. In particular, <Local-part> was updated to also support UTF8-non-ascii. UTF8-non-ascii was described by Section 3.1 of [RFC6532]. Also, domain was extended to support U-labels, as defined in [RFC5890].
subjectAltName（またはissuerAltName）拡張に、ASCII以外のローカル部分を持つ国際化された電子メールアドレスが含まれている場合、アドレスはotherNameのSmtpUTF8Mailbox名前形式で格納する必要があります。 SmtpUTF8Mailboxの形式は、ABNFルールSmtpUTF8Mailboxとして定義されています。 SmtpUTF8Mailboxは、[RFC6531]のセクション3.3で定義された国際化メールボックスの修正バージョンであり、[RFC5321]のセクション4.1.2で定義されたメールボックスから派生したものです。 [RFC6531]は、メールボックスに対して次のABNFルールを定義しています。その部分は国際化対応に変更されています：<Local-part>、<Dot-string>、<Quoted-string>、<QcontentSMTP>、<Domain>、および<Atom>。特に、<Local-part>は、UTF8-non-asciiもサポートするように更新されました。 UTF8-non-asciiは[RFC6532]のセクション3.1で説明されていました。また、[RFC5890]で定義されているように、ドメインはUラベルをサポートするように拡張されました。
This document further refines internationalized Mailbox ABNF rules as described in [RFC6531] and calls this SmtpUTF8Mailbox. In SmtpUTF8Mailbox, labels that include non-ASCII characters MUST be stored in U-label (rather than A-label) form [RFC5890]. This restriction removes the need to determine which label encoding, A- or U-label, is present in the domain. As per Section 2.3.2.1 of [RFC5890], U-labels are encoded as UTF-8 [RFC3629] in Normalization Form C and other properties specified there. In SmtpUTF8Mailbox, domain labels that solely use ASCII characters (meaning neither A-nor U-labels) SHALL use NR-LDH restrictions as specified by Section 2.3.1 of [RFC5890] and SHALL be restricted to lowercase letters. NR-LDH stands for "Non-Reserved Letters Digits Hyphen" and is the set of LDH labels that do not have "--" characters in the third and forth character position, which excludes "tagged domain names" such as A-labels. Consistent with the treatment of rfc822Name in [RFC5280], SmtpUTF8Mailbox is an envelope <Mailbox> and has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">" characters.
このドキュメントは、[RFC6531]で説明されているように国際化されたメールボックスABNFルールをさらに洗練し、これをSmtpUTF8Mailboxと呼びます。 SmtpUTF8Mailboxでは、ASCII以外の文字を含むラベルは（A-labelではなく）U-label形式で保存する必要があります[RFC5890]。この制限により、ドメインに存在するAまたはUラベルエンコーディングを判別する必要がなくなります。 [RFC5890]のセクション2.3.2.1に従って、Uラベルは正規化フォームCおよびそこで指定されているその他のプロパティでUTF-8 [RFC3629]としてエンコードされます。 SmtpUTF8Mailboxでは、ASCII文字のみを使用するドメインラベル（AラベルもUラベルも使用しない）は、[RFC5890]のセクション2.3.1で指定されているNR-LDH制限を使用する必要があり（SHALL）、小文字に制限する必要があります（SHALL）。 NR-LDHは「Non-Reserved Letters Digits Hyphen」の略で、3番目と4番目の文字位置に「-」文字を含まないLDHラベルのセットで、Aラベルなどの「タグ付きドメイン名」は除外されます。 [RFC5280]でのrfc822Nameの扱いと一致して、SmtpUTF8Mailboxはエンベロープ<Mailbox>であり、その前にフレーズ（一般名など）がなく、その後にコメント（括弧で囲まれたテキスト）がなく、「 <"および"> "文字。
Due to name constraint compatibility reasons described in Section 6, SmtpUTF8Mailbox subjectAltName MUST NOT be used unless the local-part of the email address contains non-ASCII characters. When the local-part is ASCII, rfc822Name subjectAltName MUST be used instead of SmtpUTF8Mailbox. This is compatible with legacy software that supports only rfc822Name (and not SmtpUTF8Mailbox). The appropriate usage of rfc822Name and SmtpUTF8Mailbox is summarized in Table 1 below.
セクション6で説明されている名前の制約の互換性の理由により、電子メールアドレスのローカル部分に非ASCII文字が含まれていない限り、SmtpUTF8Mailbox subjectAltNameを使用してはなりません。 local-partがASCIIの場合、SmtpUTF8Mailboxの代わりにrfc822Name subjectAltNameを使用する必要があります。これは、rfc822Nameのみをサポートする（SmtpUTF8Mailboxはサポートしない）レガシーソフトウェアと互換性があります。 rfc822NameおよびSmtpUTF8Mailboxの適切な使用法は、以下の表1に要約されています。
SmtpUTF8Mailbox is encoded as UTF8String. The UTF8String encoding MUST NOT contain a Byte-Order-Mark (BOM) [RFC3629] to aid consistency across implementations, particularly for comparison.
SmtpUTF8MailboxはUTF8Stringとしてエンコードされます。特に比較のために、実装全体の一貫性を支援するために、UTF8Stringエンコーディングには、Byte-Order-Mark（BOM）[RFC3629]を含めてはなりません（MUST NOT）。
+-----------------+-------------+--------------+-----------------+
| local-part char | domain char | domain label | subjectAltName |
+-----------------+-------------+--------------+-----------------+
| ASCII-only | ASCII-only | NR-LDH label | rfc822Name |
| non-ASCII | ASCII-only | NR-LDH label | SmtpUTF8Mailbox |
| ASCII-only | non-ASCII | A-label | rfc822Name |
| non-ASCII | non-ASCII | U-label | SmtpUTF8Mailbox |
+-----------------+-------------+--------------+-----------------+
Non-ASCII may additionally include ASCII characters.
非ASCIIには、さらにASCII文字が含まれる場合があります。
Table 1: Email Address Formatting
表1：メールアドレスのフォーマット
To facilitate comparison between email addresses, all email address domains in X.509 certificates MUST conform to IDNA2008 [RFC5890] (and avoid any "mappings" mentioned in that document). Use of non-conforming email address domains introduces the possibility of conversion errors between alternate forms. This applies to SmtpUTF8Mailbox and rfc822Name in subjectAltName, issuerAltName, and anywhere else that these are used.
電子メールアドレス間の比較を容易にするために、X.509証明書のすべての電子メールアドレスドメインはIDNA2008 [RFC5890]に準拠する必要があります（そのドキュメントで言及されている「マッピング」は避けてください）。非準拠の電子メールアドレスドメインを使用すると、代替フォーム間で変換エラーが発生する可能性があります。これは、subjectAltName、issuerAltName、およびこれらが使用される他の場所のSmtpUTF8Mailboxおよびrfc822Nameに適用されます。
In equivalence comparison with SmtpUTF8Mailbox, there may be some setup work on one or both inputs depending on whether the input is already in comparison form. Comparing SmtpUTF8Mailboxes consists of a domain part step and a local-part step. The comparison form for local-parts is always UTF-8. The comparison form for domain parts depends on context. While some contexts such as certificate path validation in [RFC5280] specify transforming domain to A-label (Sections 7.2 and 7.5 in [RFC5280] as updated by [RFC8399]), this document recommends transforming to UTF-8 U-label instead. This reduces the likelihood of errors by reducing conversions as more implementations natively support U-label domains.
SmtpUTF8Mailboxとの等価比較では、入力がすでに比較形式であるかどうかに応じて、片方または両方の入力で設定作業が行われる場合があります。 SmtpUTF8Mailboxesの比較は、ドメイン部分のステップとローカル部分のステップで構成されています。ローカル部分の比較形式は常にUTF-8です。ドメイン部分の比較フォームは、コンテキストによって異なります。 [RFC5280]の証明書パス検証などの一部のコンテキストでは、A-labelへの変換ドメインが指定されていますが（[RFC8399]によって更新される[RFC5280]のセクション7.2および7.5）、このドキュメントでは、代わりにUTF-8 U-labelへの変換を推奨しています。これにより、Uラベルドメインをネイティブにサポートする実装が増えるため、変換を減らすことでエラーの可能性を減らします。
Comparison of two SmtpUTF8Mailboxes is straightforward with no setup work needed. They are considered equivalent if there is an exact octet-for-octet match. Comparison with email addresses such as internationalized email address or rfc822Name requires additional setup steps for domain part and local-part. The initial preparation for the email addresses is to remove any phrases, comments, and "<" or ">" characters. This document calls for comparison of domain labels that include non-ASCII characters to be transformed to U-labels if not already in that form. The first step is to detect use of the A-label by using Section 5.1 of [RFC5891]. Next, if necessary, transform any A-labels (US-ASCII) to U-labels (Unicode) as specified in Section 5.2 of [RFC5891]. Finally, if necessary, convert the Unicode to UTF-8 as specified in Section 3 of [RFC3629]. For ASCII NR-LDH labels, uppercase letters are converted to lowercase letters. In setup for SmtpUTF8Mailbox, the email address local-part MUST conform to the requirements of [RFC6530] and [RFC6531], including being a string in UTF-8 form. In particular, the local-part MUST NOT be transformed in any way, such as by doing case folding or normalization of any kind. The <Local-part> part of an internationalized email address is already in UTF-8. For rfc822Name, the local-part, which is IA5String (ASCII), trivially maps to UTF-8 without change. Once setup is complete, they are again compared octet for octet.
2つのSmtpUTF8Mailboxesの比較は簡単で、セットアップ作業は必要ありません。オクテット対オクテットが完全に一致する場合、これらは同等と見なされます。国際化された電子メールアドレスやrfc822Nameなどの電子メールアドレスと比較するには、ドメイン部分とローカル部分の追加のセットアップ手順が必要です。メールアドレスの最初の準備は、フレーズ、コメント、および「<」または「>」の文字を削除することです。このドキュメントでは、ASCII以外の文字を含むドメインラベルをUラベルに変換する必要があります（まだその形式になっていない場合）。最初のステップは、[RFC5891]のセクション5.1を使用して、Aラベルの使用を検出することです。次に、必要に応じて、[RFC5891]のセクション5.2で指定されているように、Aラベル（US-ASCII）をUラベル（Unicode）に変換します。最後に、必要に応じて、[RFC3629]のセクション3で指定されているように、UnicodeをUTF-8に変換します。 ASCII NR-LDHラベルの場合、大文字は小文字に変換されます。 SmtpUTF8Mailboxの設定では、電子メールアドレスlocal-partは、UTF-8形式の文字列であることを含め、[RFC6530]および[RFC6531]の要件に準拠する必要があります。特に、local-partは、ケースフォールディングやあらゆる種類の正規化などの方法で変換してはなりません。国際化された電子メールアドレスの<Local-part>部分はすでにUTF-8です。 rfc822Nameの場合、ローカル部分であるIA5String（ASCII）は、変更せずに自明にUTF-8にマップします。セットアップが完了すると、オクテットについてオクテットが再び比較されます。
To summarize non-normatively, the comparison steps, including setup, are:
非規範的に要約すると、セットアップを含む比較手順は次のとおりです。
1. If the domain contains A-labels, transform them to U-labels.
1. ドメインにAラベルが含まれている場合は、それらをUラベルに変換します。
2. If the domain contains ASCII NR-LDH labels, lowercase them.
2. ドメインにASCII NR-LDHラベルが含まれている場合は、それらを小文字にしてください。
3. Compare strings octet for octet for equivalence.
3. 文字列オクテットとオクテットが等しいかどうかを比較します。
This specification expressly does not define any wildcard characters, and SmtpUTF8Mailbox comparison implementations MUST NOT interpret any characters as wildcards. Instead, to specify multiple email addresses through SmtpUTF8Mailbox, the certificate MUST use multiple subjectAltNames or issuerAltNames to explicitly carry any additional email addresses.
この仕様では、ワイルドカード文字を明示的に定義しておらず、SmtpUTF8Mailbox比較実装は、文字をワイルドカードとして解釈してはなりません。代わりに、SmtpUTF8Mailboxで複数のメールアドレスを指定するには、証明書で複数のsubjectAltNamesまたはissuerAltNamesを使用して、追加のメールアドレスを明示的に伝える必要があります。
This section updates Section 4.2.1.10 of [RFC5280] to extend rfc822Name name constraints to SmtpUTF8Mailbox subjectAltNames. SmtpUTF8Mailbox-aware path validators will apply name constraint comparison to the subject distinguished name and both forms of subject alternative names rfc822Name and SmtpUTF8Mailbox.
このセクションは、[RFC5280]のセクション4.2.1.10を更新して、rfc822Nameの名前の制約をSmtpUTF8Mailbox subjectAltNamesに拡張します。 SmtpUTF8Mailbox対応のパスバリデーターは、サブジェクト識別名と両方の形式のサブジェクト代替名rfc822NameおよびSmtpUTF8Mailboxに名前制約比較を適用します。
Both rfc822Name and SmtpUTF8Mailbox subject alternative names represent the same underlying email address namespace. Since legacy CAs constrained to issue certificates for a specific set of domains would lack corresponding UTF-8 constraints, [RFC8399] updates, modifies, and extends rfc822Name name constraints defined in [RFC5280] to cover SmtpUTF8Mailbox subject alternative names. This ensures that the introduction of SmtpUTF8Mailbox does not violate existing name constraints. Since it is not valid to include non-ASCII UTF-8 characters in the local-part of rfc822Name name constraints, and since name constraints that include a local-part are rarely, if at all, used in practice, name constraints updated in [RFC8399] allow the forms that represent all addresses at a host or all mailboxes in a domain and deprecates rfc822Name name constraints that represent a particular mailbox. That is, rfc822Name constraints with a local-part SHOULD NOT be used.
rfc822NameとSmtpUTF8Mailboxのサブジェクトの別名はどちらも、同じ基本的な電子メールアドレス名前空間を表します。特定のドメインセットの証明書を発行するように制限されたレガシーCAは、対応するUTF-8制約がないため、[RFC5280]で定義されているrfc822Name名の制約を更新、変更、拡張して、SmtpUTF8Mailboxサブジェクトの別名をカバーします。これにより、SmtpUTF8Mailboxの導入が既存の名前の制約に違反しないことが保証されます。 rfc822Name名前制約のローカル部分に非ASCII UTF-8文字を含めることは無効であり、ローカル部分を含む名前制約が実際に使用されることはめったにないため、[ RFC8399]は、ホストのすべてのアドレスまたはドメイン内のすべてのメールボックスを表すフォームを許可し、特定のメールボックスを表すrfc822Name名の制約を廃止します。つまり、ローカル部分を持つrfc822Name制約は使用しないでください。
Constraint comparison with SmtpUTF8Mailbox subjectAltName starts with the setup steps defined by Section 5. Setup converts the inputs of the comparison (which is one of a subject distinguished name, an rfc822Name, or an SmtpUTF8Mailbox subjectAltName, and one of an rfc822Name name constraint) to constraint comparison form. For an rfc822Name name constraint, this will convert any domain A-labels to U-labels. For both the name constraint and the subject, this will lowercase any domain NR-LDH labels. Strip the local-part and "@" separator from each rfc822Name and SmtpUTF8Mailbox, leaving just the domain part. After setup, this follows the comparison steps defined in Section 4.2.1.10 of [RFC5280] as follows. If the resulting name constraint domain starts with a "." character, then for the name constraint to match, a suffix of the resulting subject alternative name domain MUST match the name constraint (including the leading ".") octet for octet. If the resulting name constraint domain does not start with a "." character, then for the name constraint to match, the entire resulting subject alternative name domain MUST match the name constraint octet for octet.
SmtpUTF8Mailbox subjectAltNameとの制約比較は、セクション5で定義されたセットアップ手順から始まります。セットアップは、比較の入力（サブジェクト識別名、rfc822Name、またはSmtpUTF8Mailbox subjectAltName、およびrfc822Name名前制約の1つ）を制約に変換します。比較フォーム。 rfc822Nameの名前の制約の場合、これはドメインAラベルをUラベルに変換します。名前の制約とサブジェクトの両方について、これはすべてのドメインNR-LDHラベルを小文字にします。各rfc822NameとSmtpUTF8Mailboxからローカル部分と "@"セパレーターを取り除き、ドメイン部分のみを残します。セットアップ後、これは[RFC5280]のセクション4.2.1.10で定義されている比較手順に従います。結果の名前制約ドメインが「。」で始まる場合。文字、次に名前制約が一致するためには、結果のサブジェクト代替名ドメインのサフィックスがオクテットの名前制約（先頭の「。」を含む）オクテットと一致する必要があります。結果の名前制約ドメインが「。」で始まらない場合。文字、次に名前制約が一致するためには、結果のサブジェクト代替名ドメイン全体がオクテットの名前制約オクテットと一致する必要があります。
Certificate Authorities that wish to issue CA certificates with email address name constraints MUST use rfc822Name subject alternative names only. These MUST be IDNA2008-conformant names with no mappings and with non-ASCII domains encoded in A-labels only.
電子メールアドレス名の制約があるCA証明書を発行する認証局は、rfc822Nameサブジェクトの代替名のみを使用する必要があります。これらは、マッピングがなく、Aラベルのみでエンコードされた非ASCIIドメインのIDNA2008準拠の名前でなければなりません。
The name constraint requirement with SmtpUTF8Mailbox subject alternative name is illustrated in the non-normative diagram in Figure 1. The first example (1) illustrates a permitted rfc822Name ASCII-only host name name constraint and the corresponding valid rfc822Name subjectAltName and SmtpUTF8Mailbox subjectAltName email addresses. The second example (2) illustrates a permitted rfc822Name host name name constraint with A-label, and the corresponding valid rfc822Name subjectAltName and SmtpUTF8Mailbox subjectAltName email addresses. Note that an email address with ASCII-only local-part is encoded as rfc822Name despite also having Unicode present in the domain.
SmtpUTF8Mailboxサブジェクトの別名を使用した名前制約の要件を図1の非規範的な図に示します。最初の例（1）は、許可されたrfc822Name ASCIIのみのホスト名名の制約と、対応する有効なrfc822Name subjectAltNameおよびSmtpUTF8Mailbox subjectAltName電子メールアドレスを示しています。 2番目の例（2）は、Aラベル付きの許可されたrfc822Nameホスト名名制約、および対応する有効なrfc822Name subjectAltNameおよびSmtpUTF8Mailbox subjectAltName電子メールアドレスを示しています。ドメインにUnicodeが存在するにもかかわらず、ASCIIのみのローカル部分を持つ電子メールアドレスはrfc822Nameとしてエンコードされることに注意してください。
+-------------------------------------------------------------------+
| Root CA Cert |
+-------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------+
| Intermediate CA Cert |
| Permitted |
| rfc822Name: elementary.school.example.com (1) |
| |
| rfc822Name: xn--pss25c.example.com (2) |
| |
+-------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------+
| Entity Cert (w/explicitly permitted subjects) |
| SubjectAltName Extension |
| rfc822Name: student@elemenary.school.example.com (1) |
| SmtpUTF8Mailbox: u+5B66u+751F@elementary.school.example.com |
| (1) |
| |
| rfc822Name: student@xn--pss25c.example.com (2) |
| SmtpUTF8Mailbox: u+533Bu+751F@u+5927u+5B66.example.com (2) |
| |
+-------------------------------------------------------------------+
Figure 1: Name Constraints with SmtpUTF8Name and rfc822Name
図1：SmtpUTF8Nameおよびrfc822Nameを使用した名前制約
Use of SmtpUTF8Mailbox for certificate subjectAltName (and issuerAltName) will incur many of the same security considerations as in Section 8 in [RFC5280], but it introduces a new issue by permitting non-ASCII characters in the email address local-part. This issue, as mentioned in Section 4.4 of [RFC5890] and in Section 4
証明書のsubjectAltName（およびissuerAltName）にSmtpUTF8Mailboxを使用すると、[RFC5280]のセクション8と同じセキュリティ上の考慮事項の多くが発生しますが、メールアドレスのローカル部分で非ASCII文字を許可することにより、新しい問題が発生します。 [RFC5890]のセクション4.4とセクション4で言及されているこの問題
of [RFC6532], is that use of Unicode introduces the risk of visually similar and identical characters that can be exploited to deceive the recipient. The former document references some means to mitigate against these attacks. See [WEBER] for more background on security issues with Unicode.
[RFC6532]の中で、Unicodeを使用すると、視覚的に類似した同一の文字が危険にさらされ、受信者をだますために悪用される可能性があります。前者のドキュメントは、これらの攻撃を軽減するためのいくつかの手段を参照しています。 Unicodeのセキュリティ問題の背景については、[WEBER]を参照してください。
As described in Section 3 and the ASN.1 module identifier defined in Appendix A, IANA has assigned the values described here.
セクション3と付録Aで定義されているASN.1モジュール識別子で説明されているように、IANAはここで説明されている値を割り当てました。
o For the LAMPS-EaiAddresses-2016 ASN.1 module, IANA has registered value 92 for "id-mod-lamps-eai-addresses-2016" in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry.
o LAMPS-EaiAddresses-2016 ASN.1モジュールの場合、IANAは「id-mod-lamps-eai-addresses-2016」の値92を「SMI Security for PKIX Module Identifier」（1.3.6.1.5.5.7.0）に登録しましたレジストリ。
o For the SmtpUTF8Mailbox otherName, IANA has registered value 9 for id-on-SmtpUTF8Mailbox in the "SMI Security for PKIX Other Name Forms" (1.3.6.1.5.5.7.8) registry.
o SmtpUTF8Mailbox otherNameについて、IANAはid-on-SmtpUTF8Mailboxの値9を「SMI Security for PKIX Other Name Forms」（1.3.6.1.5.5.7.8）レジストリに登録しています。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[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。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<https://www.rfc-editor.org/info/rfc5321>。
[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。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<https://www.rfc-editor.org/info/ rfc5890>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、DOI 10.17487 / RFC5891、2010年8月、<https://www.rfc-editor.org/info/rfc5891>。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, <https://www.rfc-editor.org/info/rfc6530>.
[RFC6530] Klensin、J。およびY. Ko、「国際化電子メールの概要とフレームワーク」、RFC 6530、DOI 10.17487 / RFC6530、2012年2月、<https://www.rfc-editor.org/info/rfc6530>。
[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 Extension for Internationalized Email」、RFC 6531、DOI 10.17487 / RFC6531、2012年2月、<https://www.rfc-editor.org/info/rfc6531>。
[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>.
[RFC6532] Yang、A.、Steele、S。、およびN. Freed、「Internationalized Email Headers」、RFC 6532、DOI 10.17487 / RFC6532、2012年2月、<https://www.rfc-editor.org/info/ rfc6532>。
[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>。
[RFC8399] Housley, R., "Internationalization Updates to RFC 5280", RFC 8399, DOI 10.17487/RFC8399, May 2018, <https://www.rfc-editor.org/info/rfc8399>.
[RFC8399] Housley、R。、「RFC 5280の国際化の更新」、RFC 8399、DOI 10.17487 / RFC8399、2018年5月、<https://www.rfc-editor.org/info/rfc8399>。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.
[RFC5912] Hoffman、P。およびJ. Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャ用の新しいASN.1モジュール」、RFC 5912、DOI 10.17487 / RFC5912、2010年6月、<https：// www。 rfc-editor.org/info/rfc5912>。
[WEBER] Weber, C., "Attacking Software Globalization", March 2010, <https://www.lookout.net/files/ Chris_Weber_Character%20Transformations%20v1.7_IUC33.pdf>.
[WEBER] Weber、C。、「攻撃ソフトウェアのグローバリゼーション」、2010年3月、<https://www.lookout.net/files/ Chris_Weber_Character％20Transformations％20v1.7_IUC33.pdf>。
The following ASN.1 module normatively specifies the SmtpUTF8Mailbox structure. This specification uses the ASN.1 definitions from [RFC5912] with the 2002 ASN.1 notation used in that document. [RFC5912] updates normative documents using older ASN.1 notation.
次のASN.1モジュールは、SmtpUTF8Mailbox構造を標準的に指定しています。この仕様では、[RFC5912]のASN.1定義と、そのドキュメントで使用されている2002 ASN.1表記を使用しています。 [RFC5912]は、古いASN.1表記を使用して標準ドキュメントを更新します。
LAMPS-EaiAddresses-2016
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-lamps-eai-addresses-2016(92) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
OTHER-NAME
FROM PKIX1Implicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) }
id-pkix
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ;
--
-- otherName carries additional name types for subjectAltName,
-- issuerAltName, and other uses of GeneralNames.
--
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
SmtpUtf8OtherNames OTHER-NAME ::= { on-SmtpUTF8Mailbox, ... }
on-SmtpUTF8Mailbox OTHER-NAME ::= {
SmtpUTF8Mailbox IDENTIFIED BY id-on-SmtpUTF8Mailbox
}
id-on-SmtpUTF8Mailbox OBJECT IDENTIFIER ::= { id-on 9 }
SmtpUTF8Mailbox ::= UTF8String (SIZE (1..MAX))
-- SmtpUTF8Mailbox conforms to Mailbox as specified
-- in Section 3.3 of RFC 6531.
END
終わり
This non-normative example demonstrates using SmtpUTF8Mailbox as an otherName in GeneralName to encode the email address "u+8001u+5E2B@example.com".
この非規範的な例は、SmtpUTF8MailboxをGeneralNameのotherNameとして使用して、電子メールアドレス「u+8001u+5E2B@example.com」をエンコードする方法を示しています。
The hexadecimal DER encoding of the email address is: A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 6D706C65 2E636F6D
電子メールアドレスの16進数のDERエンコードは次のとおりです：A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 6D706C65 2E636F6D
The text decoding is:
0 34: [0] {
2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9'
14 20: [0] {
16 18: UTF8String '..@example.com'
: }
: }
Figure 2
図2
The example was encoded on the OSS Nokalva ASN.1 Playground and the above text decoding is an output of Peter Gutmann's "dumpasn1" program.
この例はOSS Nokalva ASN.1 Playgroundでエンコードされており、上記のテキストデコードはPeter Gutmannの「dumpasn1」プログラムの出力です。
Acknowledgements
謝辞
Thank you to Magnus Nystrom for motivating this document. Thanks to Russ Housley, Nicolas Lidzborski, Laetitia Baudoin, Ryan Sleevi, Sean Leonard, Sean Turner, John Levine, and Patrik Falstrom for their feedback. Also special thanks to John Klensin for his valuable input on internationalization, Unicode, and ABNF formatting; to Jim Schaad for his help with the ASN.1 example and his helpful feedback; and especially to Viktor Dukhovni for helping us with name constraints and his many detailed document reviews.
このドキュメントの動機を与えてくれたMagnus Nystromに感謝します。フィードバックを提供してくれたRuss Housley、Nicolas Lidzborski、Laetitia Baudoin、Ryan Sleevi、Sean Leonard、Sean Turner、John Levine、およびPatrik Falstromに感謝します。また、国際化、Unicode、およびABNFフォーマットに関する貴重な情報を提供してくれたJohn Klensinにも感謝します。 ASN.1の例に対する彼の助けと彼の有益なフィードバックについてジム・シャードに。特に、名前の制約と彼の多くの詳細なドキュメントレビューで私たちを助けてくれたViktor Dukhovniに。
Authors' Addresses
著者のアドレス
Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
Alexey Melnikov（編集者）Isode Ltd 14 Castle Mewsハンプトン、ミドルセックスTW12 2NPイギリス
Email: Alexey.Melnikov@isode.com
Weihaw Chuang (editor) Google, Inc. 1600 Amphitheater Parkway Mountain View, CA 94043 United States of America
Weihaw Chuang（編集者）Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: weihaw@google.com