RFC 9154 - Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9154.html
タイトル : RFC 9154 - 移転のための拡張可能プロビジョニングプロトコル（EPP）安全な許可情報
翻訳編集 : 自動生成

[要約] RFC 9154は、Extensible Provisioning Protocol (EPP) におけるドメイン名やその他のオブジェクトの安全な転送認証情報を提供するための拡張を定義します。この目的は、転送プロセス中のセキュリティを強化し、不正な転送を防ぐことにあります。主にドメイン名登録業者やレジストリ間のオブジェクト転送時に利用されます。

Internet Engineering Task Force (IETF)                          J. Gould
Request for Comments: 9154                                    R. Wilhelm
Category: Standards Track                                 Verisign, Inc.
ISSN: 2070-1721                                            December 2021

Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer

移転のための拡張可能プロビジョニングプロトコル（EPP）安全な許可情報

Abstract

概要

The Extensible Provisioning Protocol (EPP) (RFC 5730) defines the use of authorization information to authorize a transfer of an EPP object, such as a domain name, between clients that are referred to as "registrars". Object-specific, password-based authorization information (see RFCs 5731 and 5733) is commonly used but raises issues related to the security, complexity, storage, and lifetime of authentication information. This document defines an operational practice, using the EPP RFCs, that leverages the use of strong random authorization information values that are short lived, not stored by the client, and stored by the server using a cryptographic hash that provides for secure authorization information that can safely be used for object transfers.

Extensible Provisioning Protocol（EPP）（RFC 5730）は、「レジストラー」と呼ばれるクライアント間で、ドメイン名などのEPPオブジェクトの転送を許可するための許可情報の使用を定義しています。オブジェクト固有のパスワードベースの許可情報（RFCS 5731および5733を参照）は一般的に使用されていますが、認証情報のセキュリティ、複雑さ、ストレージ、および有効期間に関連する問題を発生させます。このドキュメントでは、EPP RFCを使用して、短期間の強いランダム認証情報の使用を活用し、クライアントによって格納されず、CANを提供するCryptographic Informationを使用してサーバーによって保存されている運用方法を定義します。オブジェクト転送に安全に使用されます。

Status of This Memo

本文書の位置付け

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

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9154で入手できます。

著作権表示

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.

この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。

Table of Contents

   1.  Introduction
     1.1.  Conventions Used in This Document
   2.  Registrant, Registrar, Registry
   3.  Signaling Client and Server Support
   4.  Secure Authorization Information
     4.1.  Secure Random Authorization Information
     4.2.  Authorization Information Time To Live (TTL)
     4.3.  Authorization Information Storage and Transport
     4.4.  Authorization Information Matching
   5.  Create, Transfer, and Secure Authorization Information
     5.1.  <Create> Command
     5.2.  <Update> Command
     5.3.  <Info> Command and Response
     5.4.  <Transfer> Request Command
   6.  Transition Considerations
     6.1.  Transition Phase 1 - Features
     6.2.  Transition Phase 2 - Storage
     6.3.  Transition Phase 3 - Enforcement
   7.  IANA Considerations
     7.1.  XML Namespace
     7.2.  EPP Extension Registry
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

The Extensible Provisioning Protocol (EPP) [RFC5730] defines the use of authorization information to authorize a transfer of an EPP object, such as a domain name, between clients that are referred to as "registrars". The authorization information is object specific and has been defined in "Extensible Provisioning Protocol (EPP) Domain Name Mapping" [RFC5731] and "Extensible Provisioning Protocol (EPP) Contact Mapping" [RFC5733] as password-based authorization information. Other authorization mechanisms can be used, but in practice the password-based authorization information has been used at the time of object creation, managed with the object update, and used to authorize an object transfer request. What has not been considered is the security of the authorization information, which includes the complexity of the authorization information, the Time To Live (TTL) of the authorization information, and where and how the authorization information is stored.

Extensible Provisioning Protocol（EPP）[RFC5730]は、ドメイン名などのEPPオブジェクトの転送を「レジストラー」と呼ばれるクライアント間で承認するための許可情報の使用を定義します。許可情報はオブジェクト固有であり、パスワードベースの許可情報として、「Extensible Provisioning Protocol（EPP）ドメイン名マッピング」[RFC5731]および「Extensible Provisioning Protocol（EPP）連絡先マッピング」[RFC5733]で定義されています。他の許可メカニズムを使用することができますが、実際には、パスワードに基づく認証情報は、オブジェクトの作成時に、オブジェクト更新で管理され、オブジェクト転送要求の承認に使用されています。考慮されていないことは、許可情報の複雑さ、許可情報のライブ時間、および許可情報の格納時間、およびどこでどのように保存されているか、およびどこでどのように保存されるかを含む、許可情報のセキュリティである。

The current/original lifecycle for authorization information involves long-term storage of encrypted (not hashed) passwords, which presents a significant latent risk of password compromise and is not consistent with current best practices. The mechanisms in this document provide a way to avoid long-term password storage entirely and to only require the storage of hashed (not retrievable) passwords instead of encrypted passwords.

認証情報のための現在の/元のライフサイクルは、暗号化された（ハッシュではない）パスワードの長期保存を含みます。この文書のメカニズムは、長期パスワードストレージを完全に回避し、暗号化されたパスワードの代わりにハッシュ化されていないパスワードのストレージのみを必要とするための方法を提供します。

This document defines an operational practice, using the EPP RFCs, that leverages the use of strong, random authorization information values that are short lived, not stored by the client, and stored by the server using a cryptographic hash to provide secure authorization information used for transfers. This operational practice can be used to support transfers of any EPP object, where the domain name object as defined in [RFC5731] is used in this document for illustration purposes. Elements of the practice may be used to support the secure use of the authorization information for purposes other than transfer, but any other purposes and the applicable elements are out of scope for this document.

このドキュメントでは、EPP RFCを使用して、クライアントによって格納されていない短いランダムな許可情報の使用を活用し、クライアントによって保存されず、暗号化ハッシュを使用してサーバーによって保存され、転送。この操作方法は、イラスト・目的のために、[RFC5731]で定義されているドメイン名オブジェクトがこの文書で使用されている任意のEPPオブジェクトの転送をサポートするために使用できます。練習の要素は、転送以外の目的のための承認情報の安全な使用をサポートするために使用されてもよいが、他の目的および該当する要素はこの文書に対して範囲外である。

The overall goal is to have strong, random authorization information values that are short lived and are either not stored or stored as cryptographic hash values by the non-responsible parties. In a registrant, registrar, and registry model, the registrant registers the object through the registrar to the registry. The registrant is the responsible party, and the registrar and the registry are the non-responsible parties. EPP is a protocol between the registrar and the registry, where the registrar is referred to as the "client" and the registry is referred to as the "server". The following are the elements of the operational practice and how the existing features of the EPP RFCs can be leveraged to satisfy them:

全体的な目標は、短い住んでいる強力でランダムな承認情報の値を持ち、責任ある締約国によって暗号化ハッシュ値として記憶または保存されていません。登録者、レジストラ、およびレジストリモデルでは、登録者はオブジェクトをレジストリにレジストリに登録します。登録者は責任者であり、レジストラとレジストリは非責任者です。EPPは、レジストラとレジストリとの間のプロトコルであり、レジストラは「クライアント」と呼ばれ、レジストリは「サーバ」と呼ばれます。以下は、運用上の練習の要素と、EPP RFCの既存の機能をそれらを満たすように活用できる方法です。

Strong Random Authorization Information: The EPP RFCs define the password-based authorization information value using an XML schema "normalizedString" type, so they don't restrict what can be used in any substantial way. This operational practice defines the recommended mechanism for creating a strong random authorization value that would be generated by the client.

強力なランダムな承認情報：EPP RFCは、XMLスキーマ「正規化ストリング」タイプを使用してパスワードベースの許可情報値を定義しているため、実質的な方法で使用できるものを制限しません。この運用慣行は、クライアントによって生成される強いランダムな許可値を作成するための推奨メカニズムを定義します。

Short-Lived Authorization Information: The EPP RFCs don't explicitly support short-lived authorization information or a TTL for authorization information, but there are EPP RFC features that can be leveraged to support short-lived authorization information. All of these features are compatible with the EPP RFCs, though not mandatory to implement. As stated in Section 2.6 of [RFC5731], authorization information is assigned when a domain object is created, which results in long-lived authorization information. This specification changes the nature of the authorization information from long lived to short lived. If authorization information is set only when a transfer is in process, the server needs to support an empty authorization information value on create, support setting and unsetting authorization information, and support automatically unsetting the authorization information upon a successful transfer. All of these features can be supported by the EPP RFCs.

短期的な承認情報：EPP RFCは、短期的な許可情報または許可情報のためのTTLを明示的にサポートしていませんが、短期間の許可情報をサポートするために活用できるEPP RFC機能があります。これらの機能はすべてEPP RFCと互換性がありますが、実装に必須ではありません。[RFC5731]のセクション2.6に記載されているように、権限情報は、ドメインオブジェクトが作成されたときに割り当てられ、それは長期的な許可情報をもたらします。この仕様は、長い間短い住んでいることから認証情報の性質を変更します。転送がプロセス中の場合にのみ認証情報が設定されている場合、サーバーは、作成、サポート設定、および不安定な許可情報の空の許可情報値をサポートし、転送が成功した場合には許可情報を自動的に設定解除する必要があります。これらの機能はすべてEPP RFCでサポートできます。

Storing Authorization Information Securely: The EPP RFCs don't specify where and how the authorization information is stored in the client or the server, so there are no restrictions on defining an operational practice for storing the authorization information securely. The operational practice will require the client to not store the authorization information and will require the server to store the authorization information using a cryptographic hash with at least a 256-bit hash function, such as SHA-256 [FIPS-180-4], and with a per-authorization information random salt with at least 128 bits. Returning the authorization information set in an EPP info response will not be supported.

許可情報を安全に保存する：EPP RFCは、許可情報がクライアントまたはサーバーに格納されている場所とどのようにどのように保存されているかを指定しないので、許可情報を安全に保存するための操作方法を定義することに制限はありません。運用慣行は、クライアントが許可情報を保存しないように要求し、SHA-256 [FIPS-180-4]のような少なくとも256ビットハッシュ関数を使用して、許可情報をサーバーに保存する必要があります。そして、少なくとも128ビットの認証毎の情報ランダムな塩。EPP Infoレスポンスで設定された認証情報を返すことはサポートされません。

1.1. Conventions Used in This Document

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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

XML [W3C.REC-xml-20081126] is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.

XML [W3C.REC-XML-20081126]は大文字と小文字を区別します。特に記載されていない限り、この文書で提供されるXML仕様および例は、適合的な実施を開発するために提示された文字の場合で解釈されなければならない。

In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and empty space in examples are provided only to illustrate element relationships and are not a required feature of this protocol.

例では、「C：」はプロトコルクライアントによって送信された行を表し、「S：」はプロトコルサーバによって返された行を表す。例のインデントと空きスペースは、要素の関係を説明するためだけに提供され、このプロトコルの必要な機能ではありません。

The examples reference XML namespace prefixes that are used for the associated XML namespaces. Implementations MUST NOT depend on the example XML namespaces and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. The example namespace prefixes used and their associated XML namespaces include the following:

例は、関連付けられているXMLネームスペースに使用されるXML名前空間プレフィックスを参照してください。実装は例のXMLネームスペースの例に依存してはならず、代わりにXML文書を解釈して出力するために適切なネームスペース対応のXMLパーサーおよびシリアライザを使用してください。使用されている名前空間プレフィックスとそれに関連付けられているXML名前空間の例には、次のものがあります。

   domain:  urn:ietf:params:xml:ns:domain-1.0

   contact:  urn:ietf:params:xml:ns:contact-1.0

2. Registrant, Registrar, Registry

2. 登録者、レジストラ、レジストリ

The EPP RFCs refer to "client" and "server", but when it comes to transfers, there are three types of actors that are involved. This document will refer to these actors as "registrant", "registrar", and "registry". [RFC8499] defines these terms formally for the Domain Name System (DNS). The terms are further described below to cover their roles as actors using the authorization information in the transfer process of any object in the registry, such as a domain name or a contact:

EPP RFCSは「クライアント」と「サーバー」を参照していますが、転送に関しては、関与するアクターの3種類があります。この文書は、これらのアクターを「登録者」、「レジストラ」、および「レジストリ」と呼びます。[RFC8499]ドメインネームシステム（DNS）に対して正式にこれらの用語を定義します。ドメイン名や連絡先などのレジストリ内の任意のオブジェクトの転送プロセスの許可情報を使用して、その役割としての役割をカバーするために、この条件をさらに説明する。

Registrant: [RFC8499] defines the registrant as "an individual or organization on whose behalf a name in a zone is registered by the registry." The registrant can be the owner of any object in the registry, such as a domain name or a contact. The registrant interfaces with the registrar for provisioning the objects. A transfer is coordinated by the registrant to transfer the sponsorship of the object from one registrar to another. The authorization information is meant to authenticate the registrant as the owner of the object to the non-sponsoring registrar and to authorize the transfer.

登録者：[RFC8499]登録者を「ゾーン内の名前がレジストリに登録されている個人または組織」として「個人または組織」を定義します。登録者は、ドメイン名や連絡先など、レジストリ内の任意のオブジェクトの所有者にすることができます。登録者は、オブジェクトをプロビジョニングするためのレジストラとインタフェースします。転送は登録者によって調整されて、オブジェクトのスポンサーシップをあるレジストラから別のレジストラに転送します。許可情報は、オブジェクトの所有者として、非スポンサーレジストラへの登録者を認証し、転送を承認することを目的としています。

Registrar: [RFC8499] defines the registrar as "a service provider that acts as a go-between for registrants and registries." The registrar interfaces with the registrant for the provisioning of objects, such as domain names and contacts, and with the registries to satisfy the registrant's provisioning requests. A registrar may (1) directly interface with the registrant or (2) indirectly interface with the registrant, typically through one or more resellers. Implementing a transfer using secure authorization information extends through the registrar's reseller channel up to the direct interface with the registrant. The registrar's interface with the registries uses EPP. The registrar's interface with its reseller channel or the registrant is registrar specific. In the EPP RFCs, the registrar is referred to as the "client", since EPP is the protocol used between the registrar and the registry. The sponsoring registrar is the authorized registrar to manage objects on behalf of the registrant. A non-sponsoring registrar is not authorized to manage objects on behalf of the registrant. A transfer of an object's sponsorship is from one registrar, referred to as the "losing registrar", to another registrar, referred to as the "gaining registrar".

レジストラ：[RFC8499]レジストラは、「登録者とレジストリの間の対策として機能するサービスプロバイダ」として定義しています。レジストラは、ドメイン名と連絡先などのオブジェクトのプロビジョニング、およびレジストリのプロビジョニング要求を満たすための登録者とインタフェースします。レジストラは、（1）登録者と直接インタフェースしてもよく、または（2）登録者と間接的にインターフェース、典型的には1つまたは複数の再販業者を通して。安全な許可情報を使用した転送を実装すると、レジストラのリセラーチャネルを介して登録者との直接インターフェースまで拡張されます。レジストリとのレジストラのインターフェースはEPPを使用します。リセラーチャネルまたは登録者を持つレジストラのインターフェースは、登録官固有です。 EPP RFCSでは、EPPはレジストラとレジストリの間で使用されるプロトコルであるため、レジストラは「クライアント」と呼ばれます。スポンサーリングレジストラは、登録者に代わってオブジェクトを管理するための承認されたレジストラです。非スポンサーレジストラは、登録者に代わってオブジェクトを管理する権限がありません。オブジェクトのスポンサーシップの転送は、「獲得レジストラ」と呼ばれる1つのレジストラから、「Gaining Registrar」と呼ばれる別のレジストラからのものです。

Registry: [RFC8499] defines the registry as "the administrative operation of a zone that allows registration of names within that zone." The registry typically interfaces with the registrars over EPP and generally does not interact directly with the registrant. In the EPP RFCs, the registry is referred to as the "server", since EPP is the protocol used between the registrar and the registry. The registry has a record of the sponsoring registrar for each object and provides the mechanism (over EPP) to coordinate a transfer of an object's sponsorship between registrars.

レジストリ：[RFC8499]レジストリを「そのゾーン内の名前の登録を可能にするゾーンの管理操作」として定義します。レジストリは通常、EPP経由でレジストラとインタフェースし、一般に登録者と直接対話しません。EPP RFCSでは、EPPはレジストラとレジストリの間で使用されるプロトコルであるため、レジストリは "Server"と呼ばれます。レジストリは、各オブジェクトのスポンサーレジストラのレコードを持ち、レジストラ間のオブジェクトのスポンサーシップの転送を調整するためのメカニズム（EPP）を提供します。

3. Signaling Client and Server Support

3. シグナリングクライアントとサーバーのサポート

This document does not define a new protocol; rather, it defines an operational practice using existing EPP features, where the client and the server can signal support for the operational practice using a namespace URI in the login and greeting extension services. The namespace URI "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0" is used to signal support for the operational practice. The client includes the namespace URI in an <svcExtension> <extURI> element of the <login> command [RFC5730]. The server includes the namespace URI in an <svcExtension> <extURI> element of the greeting [RFC5730].

この文書は新しいプロトコルを定義しません。むしろ、それは既存のEPP機能を使用して運用慣行を定義し、ここでクライアントとサーバーは、ログインおよびグリーティング・エクステンションサービスのネームスペースURIを使用して運用慣行のサポートを送信できます。ネームスペースuri "urn：ietf：params：xml：ns：secure-authinfo-transfer-1.0"は、運用慣行のサポートをシグナリングするために使用されます。クライアントには、<login> command [RFC5730]の<svcextension> <exturi>要素内のネームスペースURIが含まれています。サーバーには、グリーティングの<svcextension> <exturi>要素のネームスペースURIが含まれています[RFC5730]。

A client that receives the namespace URI in the server's greeting extension services can expect the following supported behavior by the server:

サーバーのグリーティング・エクステンション・サービス内のネームスペースURIを受信するクライアントは、サーバーによる次のサポートされている動作を期待できます。

1. Support for an empty authorization information value with a <create> command.

1. <create>コマンドで空の許可情報値をサポートします。

2. Support for unsetting authorization information with an <update> command.

2. <update>コマンドで設定されていない許可情報のサポート。

3. Support for validating authorization information with an <info> command.

3. <info>コマンドで許可情報を検証するためのサポート。

4. Support for not returning an indication of whether the authorization information is set or unset to the non-sponsoring registrar.

4. 許可情報が非スポンサーレジストラに設定されているか停止されているかどうかの表示を返さないためのサポート。

5. Support for returning an empty authorization information value to the sponsoring registrar when the authorization information is set in an info response.

5. 認証情報が情報応答に設定されている場合、空の許可情報値をスポンサーレジストラに返すためのサポート。

6. Support for allowing the passing of a matching non-empty authorization information value to authorize a transfer.

6. 一致した空の許可情報値を渡すことを可能にして、転送を許可するためのサポート。

7. Support for automatically unsetting the authorization information upon successful completion of a transfer.

7. 転送が正常に完了したら、許可情報を自動的に設定解除するためのサポート。

A server that receives the namespace URI in the client's <login> command extension services can expect the following supported behavior by the client:

クライアントの<login>コマンド拡張サービスでネームスペースURIを受信するサーバーは、クライアントによって次のサポートされている動作を期待できます。

1. Support for the generation of authorization information using a secure random value.

1. 安全なランダム値を使用して認証情報の生成をサポートします。

2. Support for only setting the authorization information when a transfer is in process.

2. 転送がプロセス中の場合にのみ認証情報を設定するためのサポート。

4. Secure Authorization Information

4. 安全な承認情報

The EPP RFCs ([RFC5731] and [RFC5733]) use password-based authorization information to support transfer with the <domain:pw> element [RFC5731] and with the <contact:pw> element [RFC5733]. Other EPP objects that support password-based authorization information for transfer can use secure authorization information as defined in this document. For authorization information to be secure, it must be generated using a strong random value and have a short TTL. The security of the authorization information is defined in the following sections.

EPP RFCS（[RFC5731]および[RFC5733]）は、<domain：pw>要素[RFC5731]と<contact：pw>要素[RFC5733]を使用して転送をサポートするためのパスワードベースの許可情報を使用しています。パスワードベースの許可情報をサポートする他のEPPオブジェクトは、このドキュメントで定義されているように安全な許可情報を使用できます。許可情報が安全であるためには、強いランダムな値を使用して生成され、短いTTLを持つ必要があります。許可情報のセキュリティは、以下のセクションで定義されています。

4.1. Secure Random Authorization Information

4.1. 安全なランダム認証情報

For authorization information to be secure, it MUST be generated using a secure random value. The authorization information is treated as a password, and the required length L of a password, rounded up to the largest whole number, is based on the size N of the set of characters and the desired entropy H, in the equation L = ROUNDUP(H / log_2 N). Given a target entropy, the required length can be calculated after deciding on the set of characters that will be randomized. In accordance with current best practices and noting that the authorization information is a machine-generated value, the implementation SHOULD use at least 128 bits of entropy as the value of H. The lengths below are calculated using that value.

許可情報が安全になるためには、安全なランダム値を使用して生成する必要があります。許可情報はパスワードとして扱われ、最大の整数まで切り上げられたパスワードの長さLは、式L = Roundupの文字のセットと目的のエントロピーHのサイズNに基づいています（h / log_2 n）。ターゲットエントロピーを考えると、ランダム化される文字のセットを決定した後に必要な長さを計算できます。現在のベストプラクティスに従って、許可情報が機械生成値であることに合わせて、実装はHの値として少なくとも128ビットのエントロピーを使用する必要があります。以下の長さはその値を使用して計算されます。

Calculation of the required length with 128 bits of entropy and with the set of all printable ASCII characters except space (0x20), which consists of the 94 characters 0x21-0x7E:

94文字0x21-0x7eで構成されるスペース（0x20）を除く全ての印刷可能なASCII文字のセット（0x20）を除く、必要な長さの計算（0x20）。

   ROUNDUP(128 / log_2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20

Calculation of the required length with 128 bits of entropy and with the set of case-insensitive alphanumeric characters, which consists of 36 characters (a-z A-Z 0-9):

128ビットのエントロピーを持つ必要な長さの計算、および36文字（a-z a-z 0-9）からなる、大文字と小文字が区別されない英数字のセットがあります。

   ROUNDUP(128 / log_2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25

The strength of the random authorization information is dependent on the random number generator. Suitably strong random number generators are available in a wide variety of implementation environments, including the interfaces listed in Sections 7.1.2 and 7.1.3 of [RFC4086]. In environments that do not provide interfaces to strong random number generators, the practices defined in [RFC4086] and Section 4.7.1 of the NIST Federal Information Processing Standards (FIPS) Publication 140-2 [FIPS-140-2] can be followed to produce random values that will be resistant to attack. (Note: FIPS 140-2 has been superseded by FIPS 140-3, but FIPS 140-3 does not contain information regarding random number generators.)

ランダムな許可情報の強度は乱数発生器に依存しています。適切に強力な乱数発生器は、[RFC4086]のセクション7.1.2および7.1.3にリストされているインターフェースを含む、さまざまな実装環境で利用可能です。強力な乱数発生器にインタフェースを提供しない環境では、[RFC4086]と[NIST連邦情報処理基準]（FIPS）Publication 140-2 [FIPS-140-2]の[RFC4086]とセクション4.7.1で定義されている慣行をに従うことができます。攻撃に対して抵抗力があるだろうランダムな値を生み出します。（注：FIPS 140-2はFIPS 140-3に置き換えられていますが、FIPS140-3は乱数発生器に関する情報を含まない。）

4.2. Authorization Information Time To Live (TTL)

4.2. 承認情報のライブ（TTL）までの時間

The authorization information SHOULD only be set when a transfer is in process. This implies that the authorization information has a TTL by which the authorization information is cleared when the TTL expires. The EPP RFCs do not provide definitions for TTL, but since the server supports the setting and unsetting of the authorization information by the sponsoring registrar, the sponsoring registrar can apply a TTL based on client policy. The TTL client policy may be based on proprietary registrar-specific criteria, which provides for a transfer-specific TTL tuned for the particular circumstances of the transaction. The sponsoring registrar will be aware of the TTL, and the sponsoring registrar MUST inform the registrant of the TTL when the authorization information is provided to the registrant.

許可情報は、転送が処理中にある場合にのみ設定する必要があります。これは、許可情報が、TTLが期限切れになると認証情報がクリアされるTTLを有することを意味する。EPP RFCはTTLの定義を提供していませんが、サーバーはスポンサーレジストラによる認可情報の設定と設定の設定をサポートしているため、スポンサーレジストラはクライアントポリシーに基づいてTTLを適用できます。TTLクライアントポリシーは、取引の特定の状況に対して調整された転送特有のTTLを提供する独自のレジストラ固有の基準に基づいている可能性があります。スポンサーレジストラはTTLを認識し、認証情報が登録者に提供されている場合、スポンサーリーケータはTTLの登録者に通知する必要があります。

4.3. Authorization Information Storage and Transport

4.3. 承認情報の保存と輸送

To protect the disclosure of the authorization information, the following requirements apply:

認証情報の開示を保護するために、以下の要件が適用されます。

1. The authorization information MUST be stored by the registry using a strong one-way cryptographic hash with at least a 256-bit hash function, such as SHA-256 [FIPS-180-4], and with a per-authorization information random salt with at least 128 bits.

1. 許可情報は、SHA-256 [FIPS-180-4]などの256ビットのハッシュ関数を持つ強力な一方向暗号ハッシュを使用してレジストリによって保存する必要があります。少なくとも128ビット。

2. An empty authorization information value MUST be stored as an undefined value that is referred to as a "NULL" value. The representation of a NULL (undefined) value is dependent on the type of database used.

2. 空の許可情報値は、「null」値と呼ばれる未定義の値として格納する必要があります。NULL（未定義）値の表現は、使用されるデータベースの種類によって異なります。

3. The authorization information MUST NOT be stored by the losing registrar.

3. 許可情報は、失うレジストラによって保存されてはいけません。

4. The authorization information MUST only be stored by the gaining registrar as a "transient" value in support of the transfer process.

4. 許可情報は、転送プロセスをサポートしている「一時的な」値として、GANYレジストラによってのみ保存されなければなりません。

5. The plain-text version of the authorization information MUST NOT be written to any logs by a registrar or the registry, nor otherwise recorded where it will persist beyond the transfer process.

5. 認可情報のプレーンテキストバージョンは、レジストラまたはレジストリによって任意のログに書き込まれてはいけません。

6. All communication that includes the authorization information MUST be over an encrypted channel (for example, see [RFC5734]) for EPP.

6. 許可情報を含むすべての通信は、EPPのための暗号化されたチャネル（たとえば、[RFC5734]を参照）を介していなければなりません。

7. The registrar's interface for communicating the authorization information with the registrant MUST be over an authenticated and encrypted channel.

7. 認証情報を登録者と通信するためのレジストラのインタフェースは、認証された暗号化されたチャネルを介していなければなりません。

4.4. Authorization Information Matching

4.4. 許可情報マッチング

To support the authorization information TTL, as described in Section 4.2, the authorization information must have either a set or unset state. Authorization information that is unset is stored with a NULL (undefined) value. Based on the requirement to store the authorization information using a strong one-way cryptographic hash, as described in Section 4.3, authorization information that is set is stored with a non-NULL hashed value. The empty authorization information value is used as input in both the <create> command (Section 5.1) and the <update> command (Section 5.2) to define the unset state. The matching of the authorization information in the <info> command (Section 5.3) and the <transfer> request command (Section 5.4) is based on the following rules:

第4.2節で説明されているように、許可情報TTLをサポートするには、認証情報はセットまたは設定解除状態のいずれかを持たなければならない。未設定の許可情報は、NULL（未定義）値で保存されています。セクション4.3で説明されているように、強力な一方向暗号ハッシュを使用して認証情報を格納する要件に基づいて、設定されている認可情報は非NULLのハッシュ値で格納されます。空の許可情報値は、<create>コマンド（セクション5.1）と<update>コマンド（セクション5.2）の両方の入力として使用され、未設定の状態を定義します。<info>コマンド（5.3項）の承認情報のマッチングと<transfer>要求コマンド（セクション5.4）は、次の規則に基づいています。

1. Any input authorization information value MUST NOT match an unset authorization information value. For example, in [RFC5731] the input <domain:pw>2fooBAR</domain:pw> must not match an unset authorization information value that used <domain:null/> or <domain:pw/>.

1. 入力許可情報の値は、設定されていない許可情報の値と一致してはいけません。たとえば、[RFC5731]では、入力<domain：pw> 2FOOBAR </ domain：pw>は、<domain：null />または<domain：pw />を使用している未設定の許可情報値と一致してはいけません。

2. An empty input authorization information value MUST NOT match any set authorization information value.

2. 空の入力許可情報値は、任意の設定許可情報値と一致してはいけません。

3. A non-empty input authorization information value MUST be hashed and matched against the set authorization information value, which is stored using the same hash algorithm.

3. 空でない入力許可情報値は、同じハッシュアルゴリズムを使用して記憶されている、設定許可情報値に対してハッシュされて一致する必要があります。

5. Create, Transfer, and Secure Authorization Information

5. 許可情報を作成、転送、および安全に保護します

To secure the transfer process using secure authorization information as described in Section 4, the client and server need to implement steps where the authorization information is set only when a transfer is actively in process and ensure that the authorization information is stored securely and transported only over secure channels. The steps for management of the authorization information for transfers include the following:

セクシャル4に記載されているように安全な許可情報を使用して転送プロセスを確保するために、クライアントとサーバーは、転送が積極的にプロセスで積極的に保存されている場合にのみ認証情報が設定され、許可情報が安全に保存されていることを確認する必要があります。安全なチャンネル転送の許可情報の管理の手順には、次のものがあります。

1. The registrant requests to register the object with the registrar. The registrar sends the <create> command with an empty authorization information value to the registry, as described in Section 5.1.

1. 登録者は、オブジェクトをレジストラに登録するように要求します。registrarは、セクション5.1で説明されているように、<create>コマンドを空の許可情報値とともにレジストリに送信します。

2. The registrant requests from the losing registrar the authorization information to provide to the gaining registrar.

2. 登録者は、承認されたレジストラの登録簿から取得登録官に提供することを要求します。

3. The losing registrar generates a secure random authorization information value and sends it to the registry, as described in Section 5.2, and then provides it to the registrant.

3. 失われたレジストラは、セクション5.2で説明されているように、安全なランダムな許可情報値を生成し、それをレジストリに送信し、それを登録者に提供します。

4. The registrant provides the authorization information value to the gaining registrar.

4. 登録者は、許可された登録官に認証情報の値を提供します。

5. The gaining registrar optionally verifies the authorization information with the <info> command to the registry, as described in Section 5.3.

5. GANICEレジストラは、セクション5.3で説明されているように、<info>コマンドをレジストリに<info>コマンドで認証情報を検証します。

6. The gaining registrar sends the transfer request with the authorization information to the registry, as described in Section 5.4.

6. 獲得レジストラは、セクション5.4で説明されているように、転送要求をレジストリ情報に送信する。

7. If the transfer completes successfully, the registry automatically unsets the authorization information; otherwise, the losing registrar unsets the authorization information when the TTL expires; see Section 5.2.

7. 転送が正常に完了した場合、レジストリは自動的に許可情報を解除します。それ以外の場合、LOSINGレジストラは、TTLが期限切れになると認証情報を解除します。セクション5.2を参照してください。

The following sections outline the practices of the EPP commands and responses between the registrar and the registry that supports secure authorization information for transfer.

次の節では、Registrarと転送のための安全な許可情報をサポートするレジストリとの間のEPPコマンドと応答の概要について説明します。

5.1. <Create> Command

5.1. <create> command.

For a <create> command, the registry MUST allow the passing of an empty authorization information value and MAY disallow the passing of a non-empty authorization information value. By having an empty authorization information value on create, the object is initially not involved in the transfer process. Any EPP object extension that supports setting the authorization information with an "eppcom:pwAuthInfoType" element can pass an empty authorization information value. Examples of such extensions are found in [RFC5731] and [RFC5733].

<create>コマンドの場合、レジストリは空の許可情報値を渡すことを許可し、空でない許可情報の渡しを許可させることができます。空の許可情報値を作成することで、オブジェクトは最初は転送プロセスに関与していません。権限情報を "eppcom：pwauthinfotype"要素に設定することをサポートするEPPオブジェクト拡張子は、空の許可情報値を渡すことができます。そのような拡張の例は、[RFC5731]および[RFC5733]に記載されている。

Example of passing an empty authorization information value in a domain name <create> command [RFC5731]:

ドメイン名に空の許可情報値を渡す例<create> command [RFC5731]：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <create>
   C:      <domain:create
   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:authInfo>
   C:          <domain:pw/>
   C:        </domain:authInfo>
   C:      </domain:create>
   C:    </create>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

Example of passing an empty authorization information value in a contact <create> command [RFC5733]:

連絡先の空の許可情報値を渡す例<create>コマンド[RFC5733]：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <create>
   C:      <contact:create
   C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
   C:        <contact:id>sh8013</contact:id>
   C:        <contact:postalInfo type="int">
   C:          <contact:name>John Doe</contact:name>
   C:          <contact:addr>
   C:            <contact:city>Dulles</contact:city>
   C:            <contact:cc>US</contact:cc>
   C:          </contact:addr>
   C:        </contact:postalInfo>
   C:        <contact:email>jdoe@example.com</contact:email>
   C:        <contact:authInfo>
   C:          <contact:pw/>
   C:        </contact:authInfo>
   C:      </contact:create>
   C:    </create>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

5.2. <Update> Command

5.2. <更新>コマンド

For an <update> command, the registry MUST allow the setting and unsetting of the authorization information. The registrar sets the authorization information by first generating a strong, random authorization information value, based on the information provided in Section 4.1, and setting it in the registry in the <update> command. The importance of generating strong authorization information values cannot be overstated: secure transfers are very important to the Internet to mitigate damage in the form of theft, fraud, and other abuse. It is critical that registrars only use strong, randomly generated authorization information values.

<update>コマンドの場合、レジストリは、許可情報の設定と設定解除を許可する必要があります。4.1項に記載されている情報に基づいて、最初に強力でランダムな許可情報値を生成し、<update>コマンドでレジストリに設定することで、登録機能を設定します。強力な認可情報の値を生成することの重要性は誇張されることはできません。安全な転送は、盗難、詐欺、その他の虐待の形の損傷を軽減するためにインターネットにとって非常に重要です。レジストラが強力でランダムに生成された許可情報の値だけを使用することは重要です。

Because of this, registries may validate the randomness of the authorization information based on the length and character set required by the registry -- for example, validating that an authorization value contains a combination of uppercase, lowercase, and non-alphanumeric characters in an attempt to assess the strength of the value and returning an EPP error result of 2202 ("Invalid authorization information") [RFC5730] if the check fails.

このため、レジストリは、レジストリによって必要とされる長さと文字セットに基づいて、認証情報のランダム性を検証することができます。たとえば、許可値が、試みで大文字、小文字、および英数字以外の文字の組み合わせを検証することができます。値の強度を評価し、2202のEPPエラー結果を返す（「無効な許可情報」）[RFC5730]チェックが失敗した場合。

Such checks are, by their nature, heuristic and imperfect, and may identify well-chosen authorization information values as being not sufficiently strong. Registrars, therefore, must be prepared for an error response of 2202 and respond by generating a new value and trying again, possibly more than once.

そのようなチェックは、それらの性質、ヒューリスティックで不完全なことによって、そして十分に強くないとしてのよく選択された許可情報の値を識別することができる。したがって、レジストラは2202のエラー応答に対して準備され、新しい値を生成して、おそらく複数回試みることによって応答する必要があります。

Often, the registrar has the "clientTransferProhibited" status set, so to start the transfer process, the "clientTransferProhibited" status needs to be removed, and the strong, random authorization information value needs to be set. The registrar MUST define a TTL, as described in Section 4.2, and if the TTL expires, the registrar will unset the authorization information.

多くの場合、レジストラは「ClientTransferProhibled」ステータスセットを設定し、転送処理を開始するために、「ClientTransferProhibled」ステータスを削除する必要があり、強力なランダムな許可情報値を設定する必要があります。4.2項で説明されているように、レジストラはTTLを定義しなければならず、TTLが期限切れになると、レジストラは許可情報を設定解除します。

Example of removing the "clientTransferProhibited" status and setting the authorization information in a domain name <update> command [RFC5731]:

"ClientTransferProibited"ステータスを削除し、許可情報のドメイン名<update> command [RFC5731]に設定する例：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <update>
   C:      <domain:update
   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:rem>
   C:          <domain:status s="clientTransferProhibited"/>
   C:        </domain:rem>
   C:        <domain:chg>
   C:          <domain:authInfo>
   C:            <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
   C:            </domain:pw>
   C:          </domain:authInfo>
   C:        </domain:chg>
   C:      </domain:update>
   C:    </update>
   C:    <clTRID>ABC-12345-XYZ</clTRID>
   C:  </command>
   C:</epp>

When the registrar-defined TTL expires, the sponsoring registrar MUST cancel the transfer process by unsetting the authorization information value and MAY add back statuses like the "clientTransferProhibited" status. Any EPP object extension that supports setting the authorization information with an "eppcom:pwAuthInfoType" element can pass an empty authorization information value. Examples of such extensions are found in [RFC5731] and [RFC5733]. Setting an empty authorization information value unsets the authorization information. [RFC5731] supports an explicit mechanism of unsetting the authorization information, by passing the <domain:null> authorization information value. The registry MUST support unsetting the authorization information by accepting an empty authorization information value and accepting an explicit unset element if it is supported by the object extension.

レジストラ定義のTTLが期限切れになると、スポンサーリーグラーは許可情報値を設定解除して転送プロセスをキャンセルする必要があり、「ClientTransferProhibed」ステータスのようなバックステータスを追加することがあります。権限情報を "eppcom：pwauthinfotype"要素に設定することをサポートするEPPオブジェクト拡張子は、空の許可情報値を渡すことができます。そのような拡張の例は、[RFC5731]および[RFC5733]に記載されている。空の許可情報の設定値を設定すると、許可情報が解除されます。[RFC5731] <domain：null>承認情報値を渡して、許可情報を除外する明示的なメカニズムをサポートします。レジストリは、空の許可情報の値を受け入れ、オブジェクト拡張によってサポートされている場合は明示的な解決済み要素を受け入れることによって、許可情報の設定解除をサポートしなければなりません。

Example of adding the "clientTransferProhibited" status and unsetting the authorization information explicitly in a domain name <update> command [RFC5731]:

"ClientTransferProibited"ステータスを追加し、ドメイン名<update> command [RFC5731]では明示的に認可情報を明示的に解除する例：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <update>
   C:      <domain:update
   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:add>
   C:          <domain:status s="clientTransferProhibited"/>
   C:        </domain:add>
   C:        <domain:chg>
   C:          <domain:authInfo>
   C:            <domain:null/>
   C:          </domain:authInfo>
   C:        </domain:chg>
   C:      </domain:update>
   C:    </update>
   C:    <clTRID>ABC-12345-XYZ</clTRID>
   C:  </command>
   C:</epp>

Example of unsetting the authorization information with an empty authorization information value in a domain name <update> command [RFC5731]:

ドメイン名<update> command [RFC5731]で空の許可情報値を使用して許可情報を設定解除する例：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <update>
   C:      <domain:update
   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:add>
   C:          <domain:status s="clientTransferProhibited"/>
   C:        </domain:add>
   C:        <domain:chg>
   C:          <domain:authInfo>
   C:            <domain:pw/>
   C:          </domain:authInfo>
   C:        </domain:chg>
   C:      </domain:update>
   C:    </update>
   C:    <clTRID>ABC-12345-XYZ</clTRID>
   C:  </command>
   C:</epp>

Example of unsetting the authorization information with an empty authorization information value in a contact <update> command [RFC5733]:

連絡先<update> command [RFC5733]に空の許可情報値を使用して許可情報を設定解除する例：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <update>
   C:      <contact:update
   C:        xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
   C:        <contact:id>sh8013</contact:id>
   C:        <contact:chg>
   C:          <contact:authInfo>
   C:            <contact:pw/>
   C:          </contact:authInfo>
   C:        </contact:chg>
   C:      </contact:update>
   C:    </update>
   C:    <clTRID>ABC-12345-XYZ</clTRID>
   C:  </command>
   C:</epp>

5.3. <Info> Command and Response

5.3. <info>コマンドとレスポンス

For an <info> command, the registry MUST allow the passing of a non-empty authorization information value for verification. The gaining registrar can pre-verify the authorization information provided by the registrant prior to submitting the transfer request with the use of the <info> command. The registry compares the hash of the passed authorization information with the hashed authorization information value stored for the object. When the authorization information is not set or the passed authorization information does not match the previously set value, the registry MUST return an EPP error result code of 2202 [RFC5730].

<info>コマンドの場合、レジストリは検証のために非空の許可情報値を渡すことを許可する必要があります。GANICEレジストラは、<info>コマンドを使用して転送要求を送信する前に、登録者によって提供される許可情報を事前に検証することができる。レジストリは、渡された許可情報のハッシュをオブジェクトに格納されているハッシュされた許可情報値と比較します。許可情報が設定されていない場合、または渡された許可情報が以前に設定された値と一致しない場合、レジストリは2202 [RFC5730]のEPPエラー結果コードを返す必要があります。

Example of passing a non-empty authorization information value in a domain name <info> command [RFC5731] to verify the authorization information value:

非空の許可情報値をドメイン名に渡す例<info> command [RFC5731]許可情報の値を確認します。

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <info>
   C:      <domain:info
   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:authInfo>
   C:          <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
   C:          </domain:pw>
   C:        </domain:authInfo>
   C:      </domain:info>
   C:    </info>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

The info response in object extensions, such as those defined in [RFC5731] and [RFC5733], MUST NOT include the optional authorization information element with a non-empty authorization value. The authorization information is stored as a hash in the registry, so returning the plain-text authorization information is not possible, unless valid plain-text authorization information is passed in the <info> command. The registry MUST NOT return any indication of whether the authorization information is set or unset to the non-sponsoring registrar by not returning the authorization information element in the response. The registry MAY return an indication to the sponsoring registrar that the authorization information is set by using an empty authorization information value. The registry MAY return an indication to the sponsoring registrar that the authorization information is unset by not returning the authorization information element.

[RFC5731]と[RFC5733]で定義されているものなど、オブジェクト拡張子の情報応答は、空でない許可値を持つオプションの許可情報要素を含んではいけません。許可情報はレジストリにハッシュとして格納されているため、有効なプレーンテキスト認証情報が<info>コマンドに渡されない限り、プレーンテキスト認証情報を返すことはできません。レジストリは、許可情報が、応答内の許可情報要素を返さないことによって、許可情報が非スポンサーレジストラに設定されているかどうかの表示を返さないでください。レジストリは、空の許可情報値を使用することによって認証情報が設定されるというスポンサーレジストラに指示を返すことができる。レジストリは、許可情報要素を返さないことによって許可情報が設定解除されることをスポンサーレジストラに表示することができる。

Example of returning an empty authorization information value in a domain name info response [RFC5731] to indicate to the sponsoring registrar that the authorization information is set:

データ名に関する空の許可情報値を返す例認可情報が設定されているスポンサーレジストラに示すように、[RFC5731]

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>
   S:    </result>
   S:    <resData>
   S:      <domain:infData
   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:name>example.com</domain:name>
   S:        <domain:roid>EXAMPLE1-REP</domain:roid>
   S:        <domain:status s="ok"/>
   S:        <domain:clID>ClientX</domain:clID>
   S:        <domain:authInfo>
   S:          <domain:pw/>
   S:        </domain:authInfo>
   S:      </domain:infData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

5.4. <Transfer> Request Command

5.4. <転送>リクエストコマンド

For a <transfer> request command, the registry MUST allow the passing of a non-empty authorization information value to authorize a transfer. The registry compares the hash of the passed authorization information with the hashed authorization information value stored for the object. When the authorization information is not set or the passed authorization information does not match the previously set value, the registry MUST return an EPP error result code of 2202 [RFC5730]. Whether the transfer occurs immediately or is pending is up to server policy. When the transfer occurs immediately, the registry MUST return the EPP success result code of 1000 ("Command completed successfully") [RFC5730], and when the transfer is pending, the registry MUST return the EPP success result code of 1001 ("Command completed successfully; action pending"). The losing registrar MUST be informed of a successful transfer request using an EPP <poll> message.

<transfer> requestコマンドの場合、レジストリは、空でない許可情報の値を渡すことを許可して転送を許可する必要があります。レジストリは、渡された許可情報のハッシュをオブジェクトに格納されているハッシュされた許可情報値と比較します。許可情報が設定されていない場合、または渡された許可情報が以前に設定された値と一致しない場合、レジストリは2202 [RFC5730]のEPPエラー結果コードを返す必要があります。転送がただちに発生するか、保留中のものであれ、サーバーポリシーまでです。転送がすぐに行われると、レジストリは1000のEPPの成功結果コードを1000（ "command完了"）[RFC5730]を返す必要があります。転送が保留中の場合、レジストリはEPP成功結果コードを1001（ "完了しました）を返す必要があります。正常に。アクション保留中）失うレジストラは、EPP <Poll>メッセージを使用して転送要求が成功したことを知らされなければなりません。

Example of passing a non-empty authorization information value in a domain name <transfer> request command [RFC5731] to authorize the transfer:

ドメイン名<transfer>要求コマンド[RFC5731]に空調でない認証情報値を渡す例転送を承認する例：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <transfer op="request">
   C:      <domain:transfer
   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example1.com</domain:name>
   C:        <domain:authInfo>
   C:          <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
   C:          </domain:pw>
   C:        </domain:authInfo>
   C:      </domain:transfer>
   C:    </transfer>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

Upon successful completion of the transfer, the registry MUST automatically unset the authorization information. If the transfer request is not submitted within the TTL (Section 4.2) or the transfer is canceled or rejected, the registrar MUST unset the authorization information, as described in Section 5.2.

転送が正常に完了すると、レジストリは自動的に許可情報を設定する必要があります。転送要求がTTL内で送信されていない場合（セクション4.2）、または転送がキャンセルまたは拒否された場合、セクション5.2で説明されているように、レジストラは許可情報を設定する必要があります。

6. Transition Considerations

6. 遷移に関する考慮事項

The goal of the transition considerations is to minimize the impact to the registrars in supporting the Secure Authorization Information Model defined in this document by supporting incremental transition steps. The transition steps are dependent on the starting point of the registry. Registries may have different starting points, since some of the elements of the Secure Authorization Information Model may have already been implemented. The considerations assume a starting point, referred to as the "Classic Authorization Information Model", which incorporates the following steps for management of the authorization information for transfers:

移行の考慮事項の目的は、増分遷移ステップをサポートすることによって、この文書で定義された安全な認可情報モデルをサポートする際のレジストラへの影響を最小限に抑えることです。遷移ステップはレジストリの開始点に依存します。安全な許可情報モデルの要素のいくつかはすでに実装されている可能性があるため、レジストリは異なる開始点を持つことがあります。考慮事項は、転送の許可情報を管理するための以下のステップを組み込んだ「古典的な認可情報モデル」と呼ばれる開始点を想定しています。

1. The registrant requests to register the object with the registrar. The registrar sends the <create> command, with a non-empty authorization information value, to the registry. The registry stores the authorization information as an encrypted value and requires a non-empty authorization information value for the life of the object. The registrar may store the long-lived authorization information.

1. 登録者は、オブジェクトをレジストラに登録するように要求します。レジストラは、空でない許可情報値を、レジストリに<create>コマンドを送信します。レジストリは、許可情報を暗号化された値として格納し、オブジェクトの寿命に対して空でない認証情報値を必要とします。レジストラは、長寿命の許可情報を記憶することができる。

2. At the time of transfer, the registrant requests from the losing registrar the authorization information to provide to the gaining registrar.

2. 転送時には、登録者は承認されたレジストラから獲得情報を獲得したレジストラに要求する。

3. The losing registrar retrieves the locally stored authorization information or queries the registry for authorization information using the <info> command, and provides it to the registrant. If the registry is queried, the authorization information is decrypted and the plain-text authorization information is returned in the info response to the registrar.

3. 失うレジストラは、ローカルに保存されている認証情報を取得するか、<info>コマンドを使用して認可情報のレジストリを照会し、それを登録者に提供します。レジストリが照会された場合、許可情報は復号化され、プレーンテキスト許可情報はレジストラへの情報応答に返されます。

4. The registrant provides the authorization information value to the gaining registrar.

4. 登録者は、許可された登録官に認証情報の値を提供します。

5. The gaining registrar optionally verifies the authorization information with the <info> command to the registry, by passing the authorization information in the <info> command to the registry.

5. 獲得レジストラは、<info>コマンドに<info>コマンドにレジストリに渡すことによって、<info>コマンドをレジストリに<info>コマンドで認証情報を検証します。

6. The gaining registrar sends the transfer request with the authorization information to the registry. The registry will decrypt the stored authorization information to compare to the passed authorization information.

6. Gaining Registrarは転送要求をレジストリに認証情報に送信します。レジストリは、渡された許可情報と比較するために、保存されている許可情報を復号化します。

7. If the transfer completes successfully, the authorization information is not touched by the registry and may be updated by the gaining registrar using the <update> command. If the transfer is canceled or rejected, the losing registrar may reset the authorization information using the <update> command.

7. 転送が正常に完了した場合、許可情報はレジストリによってタッチされず、<update>コマンドを使用して獲得レジストラによって更新されます。転送がキャンセルまたは拒否された場合、失うレジストラは<update>コマンドを使用して許可情報をリセットすることがあります。

The gaps between the Classic Authorization Information Model and the Secure Authorization Information Model include the following:

古典的承認情報モデルと安全な認可情報モデルの間のギャップには、次のものがあります。

1. Registry requirement for a non-empty authorization information value on create and for the life of the object versus the authorization information not being set on create and only being set when a transfer is in process.

1. 登録時およびオブジェクトの寿命に対する空調で非空の許可情報値に対するレジストリ要件は、転送がプロセス内に設定されているときに設定されていません。

2. Registry not allowing the authorization information to be unset versus providing support for unsetting the authorization information in the <update> command.

2. <update>コマンドで許可情報を設定解除するためのサポートを提供するための許可情報を設定解除することを許可していません。

3. Registry storing the authorization information as an encrypted value versus a hashed value.

3. 承認情報を暗号化値とハッシュ値として格納するレジストリ。

4. Registry support for returning the authorization information versus not returning the authorization information in the info response.

4. 認証情報を返すためのレジストリサポートと情報応答に許可情報を返さない。

5. Registry not touching the authorization information versus the registry automatically unsetting the authorization information upon a successful transfer.

5. レジストリは、転送が成功したときに認証情報を自動的に設定解除するレジストリに触れないでください。

6. Registry possibly validating a shorter authorization information value using password complexity rules versus validating the randomness of a longer authorization information value that meets the required bits of entropy.

6. レジストリは、パスワードの複雑さ規則を使用して短い許可情報値を検証する可能性があります。

The transition can be handled in the three phases defined in Sections 6.1, 6.2, and 6.3.

遷移は、セクション6.1,6.2、および6.3で定義されている3段階で処理できます。

6.1. Transition Phase 1 - Features

6.1. 遷移フェーズ1 - フィーチャ

The goal of "Transition Phase 1 - Features" is to implement the needed features in EPP so that the registrar can optionally implement the Secure Authorization Information Model. The features to implement are broken out by the commands and responses below:

「移行フェーズ1 - 機能」の目標は、登録機関がセキュア認証情報モデルを任意に実装できるように、EPPで必要な機能を実装することです。実装する機能は、以下のコマンドと応答によって分割されています。

<Create> Command: Change the <create> command to make the authorization information optional, by allowing both a non-empty value and an empty value. This enables a registrar to optionally create objects without an authorization information value, as described in Section 5.1.

<create> command：<create>コマンドを変更して、空白の値と空の値の両方を許可することで、許可情報をオプションにします。これにより、セクション5.1で説明されているように、レジストラは許可情報値なしでオブジェクトをオプションで作成できます。

<Update> Command: Change the <update> command to allow unsetting the authorization information, as described in Section 5.2. This enables the registrar to optionally unset the authorization information when the TTL expires or when the transfer is canceled or rejected.

<update> command：セクション5.2で説明されているように、<update>コマンドを変更するには、承認情報を設定解除できます。これにより、TTLが期限切れになったとき、または転送がキャンセルされるか拒否されたときに、レジストラは許可情報をオプションで設定解除できます。

Transfer Approve Command and Transfer Auto-Approve: Change the transfer approve command and the transfer auto-approve to automatically unset the authorization information. This sets the default state of the object to not have the authorization information set. The registrar implementing the Secure Authorization Information Model will not set the authorization information for an inbound transfer, and the registrar implementing the Classic Authorization Information Model will set the new authorization information upon a successful transfer.

転送承認コマンドと転送自動承認：転送approveコマンドを変更し、転送自動承認を自動承認して、許可情報を自動的に設定解除します。これにより、許可情報が設定されていないオブジェクトのデフォルト状態が設定されています。安全な許可情報モデルを実装するレジストラは、インバウンド転送の許可情報を設定せず、クラシック認証情報モデルを実装するレジストラは、転送が成功したときに新しい許可情報を設定します。

Info Response: Change the <info> command to not return the authorization information in the info response, as described in Section 5.3. This sets up the implementation of "Transition Phase 2 - Storage" (Section 6.2), since the dependency on returning the authorization information in the info response will be removed. This feature is the only one that is not an optional change to the registrar, and this change could potentially break the client, so it's recommended that the registry provide notice of the change.

情報処理：セクション5.3で説明されているように、<info>コマンドをINFO応答内の許可情報を返さないように変更します。これは、情報応答内の許可情報を返すことへの依存関係が削除されるため、「遷移フェーズ2 - Storage」（セクション6.2）の実装を設定します。この機能は、レジストラへのオプションの変更ではなく、この変更がクライアントを壊す可能性があるため、レジストリが変更の通知を提供することをお勧めします。

<Info> Command and Transfer Request: Change the <info> command and the transfer request to ensure that a registrar cannot get an indication that the authorization information is set or not set by returning the EPP error result code of 2202 when comparing a passed authorization to a non-matching set authorization information value or an unset value.

<info>コマンドと転送要求：<info>コマンドと転送要求を変更して、渡された許可を比較すると、認可情報が2202のEPPエラー結果コードを返すことによって許可情報が設定されているかどうかを設定できないことを確認する一致しない設定許可情報値または設定解除値。

6.2. Transition Phase 2 - Storage

6.2. 移行フェーズ2 - ストレージ

The goal of "Transition Phase 2 - Storage" is to transition the registry to use hashed authorization information instead of encrypted authorization information. There is no direct impact on the registrars, since the only visible indication that the authorization information has been hashed is that the set authorization information is not returned in the info response, as addressed in "Transition Phase 1 - Features" (Section 6.1). Transitioning the authorization information storage includes the following three steps:

「遷移フェーズ2 - Storage」の目的は、暗号化許可情報の代わりにハッシュ認証情報を使用するようにレジストリを遷移させることです。認可情報がハッシュされた唯一の目に見える表示は、「遷移フェーズ1 - 機能」でアドレス指定されているように、設定許可情報が情報応答に返されないことです。許可情報ストレージの遷移には、次の3つのステップが含まれています。

Hash New Authorization Information Values: Change the <create> command and the <update> command to hash rather than encrypt the authorization information.

HASH新規認可情報値：許可情報を暗号化するのではなく、<create>コマンドと<update>コマンドをハッシュに変更します。

Support Comparison against Encrypted or Hashed Authorization Information: Change the <info> command and the <transfer> request command to be able to compare a passed authorization information value with either a hashed or encrypted authorization information value. This requires that the stored values be self-identifying as being in hashed or encrypted form.

暗号化またはハッシュ認証情報との比較をサポート：<info>コマンドと<transfer> requestコマンドを、渡された許可情報値をハッシュされたまたは暗号化された許可情報値と比較できるようにします。これは、格納されている値がハッシュまたは暗号化された形式として自己識別することを必要とする。

Hash Existing Encrypted Authorization Information Values: Convert the encrypted authorization information values stored in the registry database to hashed values. This update will not be visible to the registrar. The conversion can be done over a period of time, depending on registry policy.

HASH既存の暗号化許可情報値：レジストリデータベースに格納されている暗号化許可情報値をハッシュされた値に変換します。この更新プログラムはレジストラには表示されません。変換は、レジストリポリシーに応じて、一定期間にわたって行うことができます。

6.3. Transition Phase 3 - Enforcement

6.3. 移行フェーズ3 - 執行

The goal of "Transition Phase 3 - Enforcement" is to complete the implementation of the Secure Authorization Information Model, by enforcing the following:

「移行フェーズ3 - 施行」の目標は、次のことを強制することで、安全な認証情報モデルの実装を完了することです。

Disallow Authorization Information on <Create> Command: Change the <create> command to not allow the passing of a non-empty authorization information value. This behavior could potentially break the client, so it's recommended that the registry provide notice of this change.

<create> command：<create>コマンドを変更するには、空でない許可情報の渡しを許可しないように変更します。この現象は潜在的にクライアントを壊す可能性があるため、レジストリはこの変更の通知を提供することをお勧めします。

Validate the Strong Random Authorization Information: Change the validation of the authorization information in the <update> command to ensure at least 128 bits of entropy.

強力なランダムな許可情報を検証します。<update>コマンドで認証情報の検証を変更して、少なくとも128ビットのエントロピーを確保します。

7. IANA Considerations

7. IANAの考慮事項

7.1. XML Namespace

7.1. XMLネームスペース

This document uses URNs to describe XML namespaces conforming to the registry mechanism described in [RFC3688]. IANA has assigned the following URI in the "ns" subregistry within the "IETF XML Registry" for secure authorization information for the transfer namespace:

このドキュメントでは、[RFC3688]に記載されているレジストリメカニズムに準拠したXMLネームスペースを記述するためにURNSを使用しています。IANAは、転送ネームスペースの安全な許可情報については、「IETF XMLレジストリ」内の「NS」サブレイストに次のURIを割り当てました。

URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0 Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification.

URI：URN：IETF：params：XML：NS：epp：secure-authinfo-transfer-1.0登録者連絡先：IESG XML：None。ネームスペースURIはXML仕様を表していません。

7.2. EPP Extension Registry

7.2. EPP拡張レジストリ

IANA has registered the EPP operational practice described in this document in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry as defined in [RFC7451]. The details of the registration are as follows:

IANAは、[RFC7451]で定義されているように、このドキュメントに記載されているEPP運用慣行を「拡張可能プロビジョニングプロトコル（EPP）」レジストリに登録しました。登録の詳細は次のとおりです。

Name of Extension: "Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer" Document status: Standards Track Reference: RFC 9154 Registrant Name and Email Address: IESG (iesg@ietf.org) TLDs: Any IPR Disclosure: None Status: Active Notes: None

拡張子の名前： "移転のための拡張可能なプロビジョニングプロトコル（EPP）の安全な認可情報"文書の状態：標準トラックリファレンス：RFC 9154登録者名と電子メールアドレス：IESG（iesg@ietf.org）TLDS：任意のIPR開示：なしステータス：アクティブメモ：なし

8. Security Considerations

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

Section 4.1 defines the use of a secure random value for the generation of authorization information. The client SHOULD choose a length and set of characters that result in at least 128 bits of entropy.

セクション4.1は、許可情報の生成のための安全なランダム値の使用を定義します。クライアントは、少なくとも128ビットのエントロピーをもたらす長さと文字のセットを選択する必要があります。

Section 4.2 defines the use of an authorization information TTL. The registrar SHOULD only set the authorization information during the transfer process by setting the authorization information at the start of the transfer process and unsetting the authorization information at the end of the transfer process. The TTL value is left up to registrar policy, and the sponsoring registrar MUST inform the registrant of the TTL when providing the authorization information to the registrant.

セクション4.2は許可情報TTLの使用を定義します。レジストラは、転送プロセスの開始時に権限情報を設定し、転送プロセスの終了時に許可情報を設定解除することによって転送プロセス中にのみ権限情報を設定する必要があります。TTL値はレジストラポリシーに登録されており、スポンサーレジストラは登録者に認証情報を提供するときにTTLの登録者に通知する必要があります。

Section 4.3 defines the storage and transport of authorization information. The losing registrar MUST NOT store the authorization information and the gaining registrar MUST only store the authorization information as a "transient" value during the transfer process, where the authorization information MUST NOT be stored after the end of the transfer process. The registry MUST store the authorization information using a one-way cryptographic hash of at least 256 bits and with a per-authorization information random salt with at least 128 bits. All communication that includes the authorization information MUST be over an encrypted channel. The plain-text authorization information MUST NOT be written to any logs by the registrar or the registry.

セクション4.3は、許可情報の保存と輸送を定義します。失うレジストラは、許可情報を保存してはいけません、および獲得レジストラは、転送プロセスの間に許可情報を「一時的な」値としてのみ保存しなければなりません。ここで、転送プロセスの終了後に許可情報を保存してはいけません。レジストリは、少なくとも256ビットの一方向暗号化ハッシュを使用して、および少なくとも128ビットの許可された情報ランダムな塩を使用して認証情報を格納しなければならない。許可情報を含むすべての通信は、暗号化されたチャネルを介していなければなりません。プレーンテキスト認証情報は、レジストラまたはレジストリによる任意のログに書き込まれてはいけません。

Section 4.4 defines the matching of the authorization information values. The registry stores an unset authorization information value as a NULL (undefined) value to ensure that an empty input authorization information value never matches it. The method used to define a NULL (undefined) value is database specific.

セクション4.4は許可情報の値の一致を定義します。レジストリは、設定されていない認証情報の値をNULL（未定義）値として保存して、空の入力許可情報値がそれに一致しないようにします。NULL（未定義）値を定義するために使用される方法は、データベース固有です。

9. References

9. 参考文献

9.1. Normative References

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

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC3688] Mealling、M.、 "IETF XML Registry"、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https：//www.rfc-editor.org/info/rfc3688>。

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4086]イーストレイク3RD、D.、Schiller、J.、S. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、2005年6月、<https：//www.rfc-編集者.ORG / INFO / RFC4086>。

[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, <https://www.rfc-editor.org/info/rfc5730>.

[RFC5730] Hollenbeck、S.、「Extensible Provisioning Protocol（EPP）」、STD 69、RFC 5730、DOI 10.17487 / RFC5730、2009年8月、<https://www.rfc-editor.org/info/rfc5730>。

[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, <https://www.rfc-editor.org/info/rfc5731>.

[RFC5731] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）ドメイン名マッピング」、STD 69、RFC 5731、DOI 10.17487 / RFC5731、2009年8月、<https：//www.rfc-editor.org/info/rfc5731>。

[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, <https://www.rfc-editor.org/info/rfc5733>.

[RFC5733] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）コンタクトマッピング」、STD 69、RFC 5733、DOI 10.17487 / RFC5733、2009年8月、<https：//www.rfc-editor.org/info/rfc5733>。

[RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport over TCP", STD 69, RFC 5734, DOI 10.17487/RFC5734, August 2009, <https://www.rfc-editor.org/info/rfc5734>.

[RFC5734] Hollenbeck、S.、TCPの拡張プロビジョニングプロトコル（EPP）トランスポート、STD 69、RFC 5734、DOI 10.17487 / RFC5734、2009年8月、<https：//www.rfc-editor.org/info/rfc5734>。

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

[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.

[RFC8499] Hoffman、P.、Sullivan、A.、K. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https：//www.rfc-editor.org/情報/ RFC8499>。

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

[W3C.REC-XML-20081126] Bray、T.、Paoli、J.、Sperberg-McQueen、M.、Maler、E.、およびF. Yergeau、「Extensible Markup Language（XML）1.0（第5版）」World Wide Web Consortium勧告Rec-XML-20081126、2008年11月、<https：//www.w3.org/tr/2008/Rec-xml-20081126>。

9.2. Informative References

9.2. 参考引用

[FIPS-140-2] National Institute of Standards and Technology, U.S. Department of Commerce, "NIST Federal Information Processing Standards (FIPS) Publication 140-2", DOI 10.6028/NIST.FIPS.140-2, May 2001, <https://csrc.nist.gov/publications/detail/fips/140/2/ final>.

[FIPS-140-2]国立標準技術研究所、米国商務省、「NIST連邦情報処理基準（FIPS）出版物140-2」、DOI 10.6028 / NIST.FIPS.140-2、<HTTPS：//csrc.nist.gov/publications/detail/fips/140/2/ final>。

[FIPS-180-4] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard, NIST Federal Information Processing Standards (FIPS) Publication 180-4", DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/ final>.

[FIPS-180-4]国立標準技術研究所、米国商務省、「セキュアハッシュスタンダード、NIST連邦情報処理基準（FIPS）出版物180-4」、DOI 10.6028 / NIST.FIPS.180-4、8月2015年、<https://csrc.nist.gov/publications/detail/fips/180/4/ final>。

[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, February 2015, <https://www.rfc-editor.org/info/rfc7451>.

[RFC7451] Hollenbeck、S。、「拡張プロビジョニングプロトコルの拡張レジストリ」、RFC 7451、DOI 10.17487 / RFC7451、2015年2月、<https：//www.rfc-editor.org/info/rfc7451>。

Acknowledgements

謝辞

The authors wish to thank the following persons for their feedback and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck, Benjamin Kaduk, Jody Kolker, Barry Leiba, Patrick Mevzek, Matthew Pozun, Srikanth Veeramachaneni, and Ulrich Wisser.

著者らは、彼らのフィードバックと提案のために次の人に感謝したいと思います：マイケルバランド、マーティンカサノバ、スコットホエンベック、ベンジャミンカドゥク、ジョディコルカー、Barry Leiba、Patrick Mevzek、Matthew Pozun、Srikanth Veeramachaneni、そしてUlrich Wisser。

Authors' Addresses

著者の住所

James Gould Verisign, Inc. 12061 Bluemont Way Reston, VA 20190 United States of America

James Gould Verisign、Inc。12061 BlueMont Way Reston、VA 20190アメリカ合衆国

   Email: jgould@verisign.com
   URI:   https://www.verisign.com

Richard Wilhelm Verisign, Inc. 12061 Bluemont Way Reston, VA 20190 United States of America

Richard Wilhelm Verisign、Inc。12061 BlueMont Way Reston、VA 20190アメリカ合衆国

   Email: 4rickwilhelm@gmail.com
   URI:   https://www.verisign.com