Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 9549 Vigil Security
Obsoletes: 8399 March 2024
Updates: 5280
Category: Standards Track
ISSN: 2070-1721
The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and includes support for internationalized email addresses in X.509 certificates. The updates ensure that name constraints for email addresses that contain only ASCII characters and internationalized email addresses are handled in the same manner. This document obsoletes RFC 8399.
このドキュメントで説明されているRFC 5280の更新は、2008年の国際化ドメイン名（IDNS）の仕様との調整を提供し、X.509証明書の国際化された電子メールアドレスのサポートが含まれています。更新により、ASCII文字と国際化された電子メールアドレスのみを含む電子メールアドレスの名前の制約が同じ方法で処理されるようになります。このドキュメントは、RFC 8399を廃止します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9549.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9549で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
1. Introduction
1.1. Terminology
1.2. Changes since RFC 8399
2. Updates to RFC 5280
2.1. Update in the Introduction (Section 1)
2.2. Update in Name Constraints (Section 4.2.1.10)
2.3. Update in IDNs in GeneralName (Section 7.2)
2.4. Update in IDNs in Distinguished Names (Section 7.3)
2.5. Update in Internationalized Electronic Mail Addresses
(Section 7.5)
3. Security Considerations
4. IANA Considerations
5. References
5.1. Normative References
5.2. Informative References
Acknowledgements
Author's Address
This document updates the Introduction in Section 1, the Name Constraints certificate extension discussion in Section 4.2.1.10, and the Processing Rules for Internationalized Names in Section 7 of RFC 5280 [RFC5280] to provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and includes support for internationalized email addresses in X.509 certificates.
このドキュメントでは、セクション1の紹介、名前がセクション4.2.1.10のセクション4.2.1.10の拡張機能の議論を制約し、RFC 5280のセクション7 [RFC5280]の国際化名の処理ルールを更新して、国際化ドメイン名の2008年の仕様と整合性を提供します（IDNS）およびX.509証明書の国際化された電子メールアドレスのサポートが含まれています。
An IDN in Unicode (native character) form contains at least one U-label [RFC5890]. IDNs are carried in certificates in ACE-encoded form. That is, all U-labels within an IDN are converted to A-labels. Conversion of a U-label to an A-label is described in [RFC5891].
Unicode（ネイティブ文字）形式のIDNには、少なくとも1つのUラベル[RFC5890]が含まれています。IDNは、ACEエンコードフォームの証明書で携帯されています。つまり、IDN内のすべてのUラベルはAラベルに変換されます。UラベルのAラベルへの変換は、[RFC5891]に記載されています。
The GeneralName structure supports many different name forms, including otherName for extensibility. RFC 8398 [RFC8398] specifies the SmtpUTF8Mailbox for internationalized email addresses.
GeneralName構造は、拡張性のためのotherNameを含む多くの異なる名前フォームをサポートしています。RFC 8398 [RFC8398]は、国際化された電子メールアドレスにSMTPUTF8MAILBOXを指定します。
Note that Internationalized Domain Names in Applications specifications published in 2003 (IDNA2003) [RFC3490] and 2008 (IDNA2008) [RFC5890] both refer to the Punycode algorithm for conversion [RFC3492].
2003年（IDNA2003）[RFC3490]および2008（IDNA2008）[RFC5890]に公開されたアプリケーション仕様の国際化ドメイン名に注意してください。
Note that characters in the Unicode Category "Symbol, Other" (So) are specifically not included in IDNA2003 [RFC3490] or IDNA2008 [RFC5890]; the derived property values for characters in this category are calculated as DISALLOWED. Thus, some characters that are allowed under the Unicode IDNA Compatibility Processing [UTS46] are not allowed under this specification. For instance, ♚.example, which contains the Unicode character U+1F0A1 (BLACK CHESS KING), results in a failure under this specification, but it becomes xn--45h.example under [UTS46].
Unicodeカテゴリ「シンボル、その他」（SO）の文字は、特にIDNA2003 [RFC3490]またはIDNA2008 [RFC5890]に含まれていないことに注意してください。このカテゴリの文字の派生プロパティ値は、許可されていないと計算されます。したがって、Unicode IDNA互換性処理[UTS46]の下で許可されている一部の文字は、この仕様では許可されていません。たとえば、Unicode文字U 1F0A1（ブラックチェスキング）を含む♚.exampleは、この仕様の下で障害をもたらしますが、[UTS46]の下でXN-45H.exampleになります。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
In some cases, [RFC8399] required conversion of A-labels to U-labels in order to process name constraints for internationalized email addresses. This led to implementation complexity and at least two security vulnerabilities. One summary of the vulnerabilities can be found in [DDHQ]. Now, all IDNs are carried and processed as A-labels.
場合によっては、[RFC8399]は、国際化された電子メールアドレスの名前の制約を処理するために、AラベルをUラベルに変換する必要がありました。これにより、実装の複雑さと少なくとも2つのセキュリティの脆弱性が発生しました。脆弱性の1つの要約は、[DDHQ]に記載されています。これで、すべてのIDNが運ばれ、Aラベルとして処理されます。
The Introduction provides a warning to implementers about the handling of characters in the Unicode Category "Symbol, Other" (So), which includes emoji characters.
はじめには、絵文字文字を含むUnicodeカテゴリ「シンボル、その他」（SO）の文字の処理について、実装者に警告を提供します。
This section provides updates to several paragraphs of [RFC5280]. For clarity, if the entire section is not replaced, then the original text and the replacement text are shown.
このセクションでは、[RFC5280]のいくつかの段落の更新を提供します。明確にするために、セクション全体が置き換えられない場合、元のテキストと交換テキストが表示されます。
This update provides references for IDNA2008.
このアップデートは、IDNA2008の参照を提供します。
OLD
古い
* Enhanced support for internationalized names is specified in Section 7, with rules for encoding and comparing Internationalized Domain Names, Internationalized Resource Identifiers (IRIs), and distinguished names. These rules are aligned with comparison rules established in current RFCs, including [RFC3490], [RFC3987], and [RFC4518].
* 国際化された名前の強化されたサポートはセクション7で指定されており、国際化されたドメイン名、国際化されたリソース識別子（IRI）、および著名な名前をエンコードして比較するためのルールがあります。これらのルールは、[RFC3490]、[RFC3987]、[RFC4518]を含む現在のRFCで確立された比較ルールと一致しています。
NEW
新しい
* Enhanced support for internationalized names is specified in Section 7, with rules for encoding and comparing Internationalized Domain Names, Internationalized Resource Identifiers (IRIs), and distinguished names. These rules are aligned with comparison rules established in current RFCs, including [RFC3987], [RFC4518], [RFC5890], and [RFC5891].
* 国際化された名前の強化されたサポートはセクション7で指定されており、国際化されたドメイン名、国際化されたリソース識別子（IRI）、および著名な名前をエンコードして比較するためのルールがあります。これらのルールは、[RFC3987]、[RFC4518]、[RFC5890]、[RFC5891]など、現在のRFCで確立された比較ルールと一致しています。
This update removes the ability to include constraints for a particular mailbox. This capability was not used, and removing it allows name constraints to apply to email addresses in rfc822Name and SmtpUTF8Mailbox [RFC8398] within otherName.
この更新により、特定のメールボックスの制約を含める機能が削除されます。この機能は使用されておらず、削除することで、名前の制約がRFC822NAMEおよびSMTPUTF8MAILBOX [RFC8398]の電子メールアドレスに他のName内で適用できます。
OLD
古い
A name constraint for Internet mail addresses MAY specify a particular mailbox, all addresses at a particular host, or all mailboxes in a domain. To indicate a particular mailbox, the constraint is the complete mail address. For example, "root@example.com" indicates the root mailbox on the host "example.com". To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the constraint "example.com" is satisfied by any mail address at the host "example.com". To specify any address within a domain, the constraint is specified with a leading period (as with URIs). For example, ".example.com" indicates all the Internet mail addresses in the domain "example.com", but not Internet mail addresses on the host "example.com".
インターネットメールアドレスの名前の制約は、特定のメールボックス、特定のホストのすべてのアドレス、またはドメイン内のすべてのメールボックスを指定する場合があります。特定のメールボックスを示すために、制約は完全なメールアドレスです。たとえば、「root@example.com」は、ホスト「Example.com」のルートメールボックスを示します。特定のホストのすべてのインターネットメールアドレスを示すために、制約はホスト名として指定されます。たとえば、制約「Example.com」は、ホスト「Example.com」のメールアドレスによって満たされます。ドメイン内のアドレスを指定するために、制約は主要期間（URISと同様）で指定されます。たとえば、「.example.com」は、ドメイン「Example.com」のすべてのインターネットメールアドレスを示しますが、ホスト「Example.com」のインターネットメールアドレスはありません。
NEW
新しい
A name constraint for Internet mail addresses MAY specify all addresses at a particular host or all mailboxes in a domain. To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the constraint "example.com" is satisfied by any mail address at the host "example.com". To specify any address within a domain, the constraint is specified with a leading period (as with URIs). For example, ".example.com" indicates all the Internet mail addresses in the domain "example.com" but not Internet mail addresses on the host "example.com".
インターネットメールアドレスの名前の制約は、特定のホストまたはドメイン内のすべてのメールボックスですべてのアドレスを指定する場合があります。特定のホストのすべてのインターネットメールアドレスを示すために、制約はホスト名として指定されます。たとえば、制約「Example.com」は、ホスト「Example.com」のメールアドレスによって満たされます。ドメイン内のアドレスを指定するために、制約は主要期間（URISと同様）で指定されます。たとえば、「.example.com」は、ドメイン「Example.com」のすべてのインターネットメールアドレスを示しますが、ホスト「Example.com」のインターネットメールアドレスはありません。
This update aligns with IDNA2008. Since all of Section 7.2 of [RFC5280] is replaced, the OLD text is not provided.
この更新はIDNA2008と一致します。[RFC5280]のセクション7.2はすべて交換されているため、古いテキストは提供されていません。
NEW
新しい
Internationalized Domain Names (IDNs) may be included in certificates and CRLs in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, CRL distribution points extension, and issuing distribution point extension. Each of these extensions uses the GeneralName type; one choice in GeneralName is the dNSName field, which is defined as type IA5String.
国際化されたドメイン名（IDN）は、subjectaltnameおよびissueraltname拡張機能の証明書とCRLSに含まれている場合があります。これらの各拡張機能は、一般名のタイプを使用します。一般名の1つの選択肢はDNSNameフィールドです。これは、タイプIA5ストリングとして定義されています。
IA5String is limited to the set of ASCII characters. To accommodate IDNs, U-labels are converted to A-labels. The A-label is the encoding of the U-label according to the Punycode algorithm [RFC3492] with the ACE prefix "xn--" added at the beginning of the string.
IA5Stringは、ASCII文字のセットに限定されています。IDNに対応するために、UラベルはAラベルに変換されます。A-Labelは、文字列の先頭に追加されたACEプレフィックス「xn-」を備えた、Punycodeアルゴリズム[RFC3492]に従って、U-Labelのエンコードです。
When comparing DNS names for equality, conforming implementations MUST perform a case-insensitive exact match on the entire DNS name. When evaluating name constraints, conforming implementations MUST perform a case-insensitive exact match on a label-by-label basis. As noted in Section 4.2.1.10, any DNS name that may be constructed by adding labels to the left-hand side of the domain name given as the constraint is considered to fall within the indicated subtree.
DNS名を平等の名前を比較する場合、適合実装は、DNS名全体でケースに依存しない正確な一致を実行する必要があります。名前の制約を評価する場合、適合の実装は、ラベルごとにケースに依存しない正確な一致を実行する必要があります。セクション4.2.1.10に記載されているように、制約が指定されたサブツリー内に収まると見なされるため、ドメイン名の左側にラベルを追加することで構築されるDNS名。
Implementations that have a user interface SHOULD convert IDNs to Unicode for display. Specifically, conforming implementations convert A-labels to U-labels for display purposes.
ユーザーインターフェイスを持つ実装は、IDNをUnicodeに変換して表示する必要があります。具体的には、実装を適合させると、A-Labelを表示目的でUラベルに変換します。
Implementation consideration: There are increased memory requirements for IDNs. An IDN ACE label will begin with the four additional characters "xn--", and an IDN can require as many as five ASCII characters to specify a single international character.
実装の考慮事項：IDNのメモリ要件が増加しています。IDN ACEラベルは、4つの追加文字「XN-」から始まり、IDNは1つの国際文字を指定するために5つのASCII文字を必要とすることができます。
This update aligns with IDNA2008.
この更新はIDNA2008と一致します。
OLD
古い
Domain Names may also be represented as distinguished names using domain components in the subject field, the issuer field, the subjectAltName extension, or the issuerAltName extension. As with the dNSName in the GeneralName type, the value of this attribute is defined as an IA5String. Each domainComponent attribute represents a single label. To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in Section 4.1 of RFC 3490. The label SHALL be considered a "stored string". That is, the AllowUnassigned flag SHALL NOT be set.
ドメイン名は、サブジェクトフィールド、発行者フィールド、subjectaltname拡張機能、またはinsueraltname拡張機能のドメインコンポーネントを使用して、著名な名前として表現することもできます。一般名のdnsnameと同様に、この属性の値はia5stringとして定義されます。各ドメインコンポーネント属性は、単一のラベルを表します。著名な名前のIDNからのラベルを表すには、実装はRFC 3490のセクション4.1で指定された「TOASCII」ラベル変換を実行する必要があります。ラベルは「保存された文字列」と見なされます。つまり、Allowunassigned Flagは設定してはなりません。
NEW
新しい
Domain names may also be represented as distinguished names using domain components in the subject field, the issuer field, the subjectAltName extension, or the issuerAltName extension. As with the dNSName in the GeneralName type, the value of this attribute is defined as an IA5String. Each domainComponent attribute represents a single label. To represent a label from an IDN in the distinguished name, the implementation MUST convert all U-labels to A-labels.
ドメイン名は、サブジェクトフィールド、発行者フィールド、subjectaltname拡張機能、またはinsueraltname拡張機能のドメインコンポーネントを使用して、著名な名前として表現することもできます。一般名のdnsnameと同様に、この属性の値はia5stringとして定義されます。各ドメインコンポーネント属性は、単一のラベルを表します。著名な名前のIDNからのラベルを表すには、実装はすべてのUラベルをAラベルに変換する必要があります。
This update aligns with IDNA2008 and [RFC8398]. Since all of Section 7.5 of [RFC5280] is replaced, the OLD text is not provided.
この更新は、IDNA2008および[RFC8398]と一致します。[RFC5280]のセクション7.5はすべて交換されているため、古いテキストは提供されていません。
NEW
新しい
Electronic Mail addresses may be included in certificates and CRLs in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, issuing distribution point extension, or CRL distribution points extension. Each of these extensions uses the GeneralName construct. If the email address includes an IDN but the local-part of the email address can be represented in ASCII, then the email address is placed in the rfc822Name choice of GeneralName, which is defined as type IA5String. If the local-part of the internationalized email address cannot be represented in ASCII, then the internationalized email address is placed in the otherName choice of GeneralName using the conventions in RFC 8398 [RFC8398].
電子メールアドレスは、subjectaltnameおよびissuelaltname拡張機能、名前制約拡張、権限情報アクセス拡張、サブジェクト情報アクセス拡張、配信ポイント拡張の発行、またはCRL配布ポイント拡張の証明書およびCRLSに含まれる場合があります。これらの拡張機能のそれぞれは、一般名構造を使用します。電子メールアドレスにIDNが含まれているが、電子メールアドレスのローカルパートをASCIIで表すことができる場合、電子メールアドレスは、タイプIA5STRINGとして定義されているgeneralNameのRFC822Name選択に配置されます。国際化されたメールアドレスのローカルパートをASCIIで表すことができない場合、RFC 8398 [RFC8398]の規則を使用して、国際化されたメールアドレスが一般名の他の選択肢に配置されます。
When the host-part contains an IDN, conforming implementations MUST convert all U-labels to A-labels.
ホストパートにIDNが含まれている場合、適合実装はすべてのUラベルをAラベルに変換する必要があります。
7.5.1. Local-Part Contains Only ASCII Characters
7.5.1. ローカルパートには、ASCII文字のみが含まれています
Two email addresses are considered to match if:
次の場合、2つのメールアドレスが一致すると見なされます。
1) The local-part of each name is an exact match, AND
1) 各名前のローカルパートは正確な一致であり、
2) The host-part of each name matches using a case-insensitive ASCII comparison.
2) 各名前のホスト部品は、ケースに依存しないASCII比較を使用して一致します。
Implementations that have a user interface SHOULD convert the host-part of internationalized email addresses specified in these extensions to Unicode before display. Specifically, conforming implementations convert A-labels to U-labels for display purposes.
ユーザーインターフェイスを持つ実装は、これらの拡張機能で指定された国際化された電子メールアドレスのホストパートを、表示前にUnicodeに変換する必要があります。具体的には、実装を適合させると、A-Labelを表示目的でUラベルに変換します。
7.5.2. Local-Part Contains Non-ASCII Characters
7.5.2. ローカルパートには、ASCII以外の文字が含まれています
When the local-part contains non-ASCII characters, conforming implementations MUST place the internationalized email address in the SmtpUTF8Mailbox within the otherName choice of GeneralName as specified in Section 3 of RFC 8398 [RFC8398]. Note that the UTF8 encoding of the internationalized email address MUST NOT contain a Byte-Order-Mark (BOM) [RFC3629] to aid comparison. The email address local-part within the SmtpUTF8Mailbox MUST conform to the requirements of [RFC6530] and [RFC6531].
ローカルパートに非ASCII文字が含まれている場合、適合実装は、RFC 8398 [RFC8398]のセクション3で指定されているように、generalNameの他の名前の選択肢内にSMTPUTF8Mailboxに国際化された電子メールアドレスを配置する必要があります。国際化された電子メールアドレスのUTF8エンコーディングには、比較を支援するためにバイトオーダーマーク（BOM）[RFC3629]が含まれていないことに注意してください。SMTPUTF8Mailbox内の電子メールアドレスは、[RFC6530]および[RFC6531]の要件に準拠する必要があります。
Two email addresses are considered to match if:
次の場合、2つのメールアドレスが一致すると見なされます。
1) The local-part of each name is an exact match, AND
1) 各名前のローカルパートは正確な一致であり、
2) The host-part of each name matches using a case-insensitive ASCII comparison.
2) 各名前のホスト部品は、ケースに依存しないASCII比較を使用して一致します。
Implementations that have a user interface SHOULD convert the host-part of internationalized email addresses specified in these extensions to Unicode before display. Specifically, conforming implementations convert A-labels to U-labels for display purposes.
ユーザーインターフェイスを持つ実装は、これらの拡張機能で指定された国際化された電子メールアドレスのホストパートを、表示前にUnicodeに変換する必要があります。具体的には、実装を適合させると、A-Labelを表示目的でUラベルに変換します。
The Security Considerations related to internationalized names in Section 4 of [RFC5890] are relevant to this specification.
[RFC5890]のセクション4の国際化された名前に関連するセキュリティ上の考慮事項は、この仕様に関連しています。
Conforming Certification Authorities (CAs) SHOULD ensure that IDNs are valid according to IDNA2008, which is defined in [RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894], and the updates to these documents. Failure to use valid A-labels may yield a domain name that cannot be correctly represented in the Domain Name System (DNS). In addition, the CA/Browser Forum offers some guidance regarding internal server names in certificates [CABF].
適合認証局（CAS）は、[RFC5890]、[RFC5892]、[RFC5892]、[RFC5893]、[RFC5894]、[RFC5894]、およびこれらの文書への更新で定義されているIDNA2008に従ってIDNが有効であることを確認する必要があります。有効なAラベルを使用しないと、ドメイン名システム（DNS）で正しく表現できないドメイン名が生成される場合があります。さらに、CA/ブラウザフォーラムは、証明書[CABF]の内部サーバー名に関するガイダンスを提供しています。
An earlier version of this specification [RFC8399] required conversion of A-labels to U-labels in order to process name constraints for internationalized email addresses in SmtpUTF8Mailbox other names. This led to implementation complexity and at least two security vulnerabilities. Now, all IDNs are carried and processed as A-labels.
この仕様[RFC8399]の以前のバージョンでは、smtputf8mailbox他の名前の国際化された電子メールアドレスの名前の制約を処理するために、aラベルからUラベルへの変換が必要でした。これにより、実装の複雑さと少なくとも2つのセキュリティの脆弱性が発生しました。これで、すべてのIDNが運ばれ、Aラベルとして処理されます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<https://www.rfc-editor.org/info/rfc3492>.
[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>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
January 2005, <https://www.rfc-editor.org/info/rfc3987>.
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Internationalized String Preparation", RFC 4518,
DOI 10.17487/RFC4518, June 2006,
<https://www.rfc-editor.org/info/rfc4518>.
[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>.
[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>.
[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>.
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)",
RFC 5892, DOI 10.17487/RFC5892, August 2010,
<https://www.rfc-editor.org/info/rfc5892>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
for Internationalized Domain Names for Applications
(IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
<https://www.rfc-editor.org/info/rfc5893>.
[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>.
[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>.
[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>.
[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>.
[CABF] CA/Browser Forum, "Internal Server Names and IP Address
Requirements for SSL: Guidance on the Deprecation of
Internal Server Names and Reserved IP Addresses provided
by the CA/Browser Forum", Version 1.0, June 2012,
<https://cabforum.org/internal-names/>.
[DDHQ] Datadog Security Labs, "The OpenSSL punycode vulnerability
(CVE-2022-3602): Overview, detection, exploitation, and
remediation", 1 November 2022,
<https://securitylabs.datadoghq.com/articles/openssl-
november-1-vulnerabilities/>.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, DOI 10.17487/RFC3490, March 2003,
<https://www.rfc-editor.org/info/rfc3490>.
[RFC5894] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and
Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
<https://www.rfc-editor.org/info/rfc5894>.
[RFC8399] Housley, R., "Internationalization Updates to RFC 5280",
RFC 8399, DOI 10.17487/RFC8399, May 2018,
<https://www.rfc-editor.org/info/rfc8399>.
[UTS46] Davis, M. and M. Suignard, "Unicode Technical Standard
#46: Unicode IDNA Compatibility Processing", Revision 31,
The Unicode Consortium, Mountain View, September 2023,
<https://www.unicode.org/reports/tr46>.
Thanks to David Benjamin and Wei Chuang for identifying the issue and a solution.
問題と解決策を特定してくれたDavid BenjaminとWei Chuangに感謝します。
Thanks to Takahiro Nemoto, John Klensin, Mike Ounsworth, and Orie Steele for their careful review and thoughtful comments.
nemohiro、nemoto、ジョン・クレンシン、マイク・オンスワース、オリー・スティールの慎重なレビューと思慮深いコメントに感謝します。
Russ Housley
Vigil Security, LLC
Herndon, VA
United States of America
Email: housley@vigilsec.com