RFC 8399 - Internationalization Updates to RFC 5280 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8399
タイトル : RFC 8399 - RFC 5280の国際化の更新
翻訳編集 : 自動生成

[要約] RFC 8399は、RFC 5280に国際化の更新を提供するものであり、主な目的は、X.509証明書の国際化に関連する問題を解決し、グローバルな展開をサポートすることです。

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 8399                                Vigil Security
Updates: 5280                                                   May 2018
Category: Standards Track
ISSN: 2070-1721

Internationalization Updates to RFC 5280

RFC 5280の国際化の更新

Abstract

概要

The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates.

このドキュメントで説明されているRFC 5280の更新は、国際化ドメイン名（IDN）の2008仕様との整合性を提供し、X.509証明書の国際化電子メールアドレスのサポートを追加します。

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/rfc8399.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8399で入手できます。

著作権表示

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に記載されているように保証なしで提供されます。

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標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................3
   2. Updates to RFC 5280 .............................................3
      2.1. Update in the Introduction (Section 1) .....................4
      2.2. Update in Name Constraints (Section 4.2.1.10) ..............4
      2.3. Update in IDNs in GeneralName (Section 7.2) ................5
      2.4. Update in IDNs in Distinguished Names (Section 7.3) ........6
      2.5. Update in Internationalized Electronic Mail
           Addresses (Section 7.5) ....................................6
   3. Security Considerations .........................................7
   4. IANA Considerations .............................................8
   5. References ......................................................8
      5.1. Normative References .......................................8
      5.2. Informative References .....................................9
   Acknowledgements ...................................................9
   Author's Address ...................................................9

1. Introduction

1. はじめに

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 add support for internationalized email addresses in X.509 certificates.

このドキュメントは、セクション1の概要、セクション4.2.1.10の名前制約証明書拡張の説明、およびRFC 5280 [RFC5280]のセクション7の国際化名の処理規則を更新して、国際化ドメイン名（IDN）の2008仕様との整合性を提供します。）およびX.509証明書に国際化された電子メールアドレスのサポートを追加します。

An IDN in Unicode (native character) form contains at least one U-label [RFC5890]. With one exception, 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]が含まれています。 1つの例外を除いて、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, which includes IDNs with U-labels.

GeneralName構造は、拡張性のためのotherNameを含む、さまざまな名前の形式をサポートしています。 RFC 8398 [RFC8398]は、国際化された電子メールアドレス用のSmtpUTF8Mailboxを指定します。これには、Uラベル付きのIDNが含まれます。

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]で公開されたアプリケーション仕様の国際化ドメイン名は、どちらも変換用のPunycodeアルゴリズム[RFC3492]を参照していることに注意してください。

1.1. Terminology

1.1. 用語

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]で説明されているように解釈されます。

2. Updates to RFC 5280

2. RFC 5280の更新

This section provides updates to several paragraphs of RFC 5280 [RFC5280]. For clarity, if the entire section is not replaced, then the original text and the replacement text are shown.

このセクションでは、RFC 5280 [RFC5280]のいくつかの段落に対する更新を提供します。明確にするために、セクション全体が置き換えられない場合は、元のテキストと置換テキストが表示されます。

2.1. Update in the Introduction (Section 1)

2.1. はじめにの更新（セクション1）

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

新着

* 国際化された名前の拡張サポートはセクション7で指定され、国際化されたドメイン名、国際化されたリソース識別子（IRI）、および識別名をエンコードおよび比較するためのルールが含まれます。これらのルールは、[RFC3987]、[RFC4518]、[RFC5890]、[RFC5891]など、現在のRFCで確立された比較ルールと整合しています。

2.2. Update in Name Constraints (Section 4.2.1.10)

2.2. 名前制約の更新（セクション4.2.1.10）

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.

このアップデートでは、特定のメールボックスの制約を含める機能が削除されています。この機能は使用されませんでした。これを削除すると、名前の制約をotherName内のrfc822NameおよびSmtpUTF8Mailbox [RFC8398]の電子メールアドレスに適用できます。

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」のメールアドレスによって満たされます。ドメイン内のアドレスを指定するには、（URIと同様に）先頭にピリオドを付けて制約を指定します。たとえば、「。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」のメールアドレスによって満たされます。ドメイン内のアドレスを指定するには、（URIと同様に）先頭にピリオドを付けて制約を指定します。たとえば、「。example.com」は、ドメイン「example.com」内のすべてのインターネットメールアドレスを示しますが、ホスト「example.com」上のインターネットメールアドレスは示しません。

2.3. Update in IDNs in GeneralName (Section 7.2)

2.3. GeneralNameのIDNの更新（セクション7.2）

This update aligns with IDNA2008. Since all of Section 7.2 is replaced, the OLD text is not provided.

この更新は、IDNA2008に対応しています。セクション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拡張機能、名前制約拡張機能、機関情報アクセス拡張機能、サブジェクト情報アクセス拡張機能、CRL配布ポイント拡張機能、および発行配布ポイント拡張機能の証明書およびCRLに含まれる場合があります。これらの各拡張機能はGeneralNameタイプを使用します。 GeneralNameの1つの選択肢は、タイプIA5Stringとして定義されているdNSNameフィールドです。

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ラベルは、文字列の先頭にACEプレフィックス「xn--」が追加されたPunycodeアルゴリズム[RFC3492]に従ったUラベルのエンコーディングです。

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 SHOULD convert IDNs to Unicode before display. Specifically, conforming implementations convert A-labels to U-labels for display.

実装は、表示する前にIDNをUnicodeに変換する必要があります。具体的には、準拠する実装はAラベルを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は単一の国際文字を指定するために最大5つのASCII文字を必要とする場合があります。

2.4. Update in IDNs in Distinguished Names (Section 7.3)

2.4. 識別名のIDNの更新（7.3節）

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拡張機能、またはissuerAltName拡張機能のドメインコンポーネントを使用して、識別名として表すこともできます。 GeneralNameタイプのdNSNameと同様に、この属性の値はIA5Stringとして定義されます。各domainComponent属性は単一のラベルを表します。識別名でIDNからのラベルを表すために、実装はRFC 3490のセクション4.1で指定された「ToASCII」ラベル変換を実行する必要があります。ラベルは「格納された文字列」と見なされる必要があります（SHALL）。つまり、AllowUnassignedフラグを設定することはできません。

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拡張機能、またはissuerAltName拡張機能のドメインコンポーネントを使用して、識別名として表すこともできます。 GeneralNameタイプのdNSNameと同様に、この属性の値はIA5Stringとして定義されます。各domainComponent属性は単一のラベルを表します。 IDNのラベルを識別名で表すには、実装ですべてのUラベルをAラベルに変換する必要があります。

2.5. Update in Internationalized Electronic Mail Addresses (Section 7.5)

2.5. 国際化された電子メールアドレスの更新（第7.5項）

This update aligns with IDNA2008 and RFC 8398 [RFC8398]. Since all of Section 7.5 is replaced, the OLD text is not provided.

この更新は、IDNA2008およびRFC 8398 [RFC8398]に対応しています。セクション7.5はすべて置き換えられるため、OLDテキストは提供されません。

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およびissuerAltName拡張機能、名前制約拡張機能、機関情報アクセス拡張機能、件名情報アクセス拡張機能、発行配布ポイント拡張機能、またはCRL配布ポイント拡張機能の証明書およびCRLに含まれている場合があります。これらの各拡張機能はGeneralName構成を使用します。電子メールアドレスにIDNが含まれているが、電子メールアドレスのローカル部分をASCIIで表すことができる場合、電子メールアドレスは、IA5Stringタイプとして定義されているGeneralNameのrfc822Name選択に配置されます。国際化された電子メールアドレスのローカル部分をASCIIで表すことができない場合、国際化された電子メールアドレスは、RFC 8398 [RFC8398]の規則を使用してGeneralNameのotherName選択に配置されます。

7.5.1. Local-Part Contains Only ASCII Characters

7.5.1. ローカル部分にはASCII文字のみが含まれます

Where the host-part contains an IDN, conforming implementations MUST convert all U-labels to A-labels.

ホスト部分にIDNが含まれている場合、準拠する実装はすべてのUラベルをAラベルに変換する必要があります。

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 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.

実装は、これらの拡張で指定された国際化された電子メールアドレスのホスト部分を表示前にUnicodeに変換する必要があります。具体的には、準拠する実装はAラベルを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.

local-partに非ASCII文字が含まれている場合、準拠する実装では、RFC 8398 [RFC8398]のセクション3で指定されているGeneralNameのotherName選択内のSmtpUTF8Mailboxに国際化された電子メールアドレスを配置する必要があります。国際化された電子メールアドレスのUTF8エンコーディングには、比較を容易にするために、Byte-Order-Mark（BOM）[RFC3629]を含めてはならないことに注意してください。

The comparison of two internationalized email addresses is specified in Section 5 of RFC 8398 [RFC8398].

2つの国際化された電子メールアドレスの比較は、RFC 8398 [RFC8398]のセクション5で指定されています。

3. Security Considerations

3. セキュリティに関する考慮事項

Conforming CAs SHOULD ensure that IDNs are valid. This can be done by validating all code points according to IDNA2008 [RFC5892]. Failure to use valid A-labels and valid U-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].

適合CAは、IDNが有効であることを確認する必要があります。これは、IDNA2008 [RFC5892]に従ってすべてのコードポイントを検証することで実行できます。有効なAラベルと有効なUラベルを使用しないと、ドメインネームシステム（DNS）で正しく表現できないドメイン名が生成される可能性があります。さらに、CA /ブラウザフォーラムでは、証明書内の内部サーバー名に関するいくつかのガイダンスを提供しています[CABF]。

4. IANA Considerations

4. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[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>。

[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>.

[RFC3492] Costello、A。、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、DOI 10.17487 / RFC3492、2003年3月、<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>.

[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<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>.

[RFC3987] Duerst、M。およびM. Suignard、「Internationalized Resource Identifiers（IRIs）」、RFC 3987、DOI 10.17487 / RFC3987、2005年1月、<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>.

[RFC4518] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：Internationalized String Preparation」、RFC 4518、DOI 10.17487 / RFC4518、2006年6月、<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>.

[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>。

[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>。

[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>.

[RFC5892] Faltstrom、P。、編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）」、RFC 5892、DOI 10.17487 / RFC5892、2010年8月、<https://www.rfc-editor.org / info / rfc5892>。

[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", DOI 10.17487/RFC8398, May 2016, <http://www.rfc-editor.org/info/rfc8398>.

[RFC8398] Melnikov、A.、Ed。 W.チュアン編、「X.509証明書の国際化された電子メールアドレス」、DOI 10.17487 / RFC8398、2016年5月、<http://www.rfc-editor.org/info/rfc8398>。

5.2. Informative References

5.2. 参考引用

[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/>.

[CABF] CA /ブラウザフォーラム、「SSLの内部サーバー名とIPアドレスの要件：CA /ブラウザフォーラムによって提供される内部サーバー名と予約済みIPアドレスの非推奨に関するガイダンス」、バージョン1.0、2012年6月、<https：/ /cabforum.org/internal-names/>。

[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>.

[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「Internationalizing Domain Names in Applications（IDNA）」、RFC 3490、DOI 10.17487 / RFC3490、2003年3月、<https：//www.rfc-editor .org / info / rfc3490>。

Acknowledgements

謝辞

Thanks to Alexey Melnikov for the encouragement to write this update. Thanks to John Klensin and Patrik Falstrom for confirming many of the details in this update. Thanks to Ben Campbell, Wei Chuang, Spencer Dawkins, Phillip Hallam-Baker, Warren Kumari, Alexey Melnikov, Adam Roach, Tim Ruehsen, and Sean Turner for their careful review and comments.

このアップデートを書くように勧めてくれたAlexey Melnikovに感謝します。この更新の詳細の多くを確認してくれたJohn KlensinとPatrik Falstromに感謝します。ベンキャンベル、ウェイチュアン、スペンサードーキンス、フィリップハラムベイカー、ウォーレンクマリ、アレクセイメルニコフ、アダムローチ、ティムルーセン、ショーンターナーの慎重なレビューとコメントに感謝します。

Author's Address

著者のアドレス

Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States of America

Russ Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170アメリカ合衆国

   Email: housley@vigilsec.com