--- 1/draft-ietf-regext-epp-eai-09.txt 2022-05-23 08:13:26.284709968 -0700 +++ 2/draft-ietf-regext-epp-eai-10.txt 2022-05-23 08:13:26.316710786 -0700 @@ -1,20 +1,20 @@ Network Working Group D. Belyavskiy Internet-Draft Intended status: Standards Track J. Gould -Expires: 23 November 2022 VeriSign, Inc. - 22 May 2022 +Expires: 24 November 2022 VeriSign, Inc. + 23 May 2022 Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP) - draft-ietf-regext-epp-eai-09 + draft-ietf-regext-epp-eai-10 Abstract This document describes an EPP extension that permits usage of Internationalized Email Addresses in the EPP protocol and specifies the terms when it can be used by EPP clients and servers. The Extensible Provisioning Protocol (EPP), being developed before appearing the standards for Internationalized Email Addresses (EAI), does not support such email addresses. @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 23 November 2022. + This Internet-Draft will expire on 24 November 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -84,21 +84,23 @@ A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 11 A.5. Change from 04 to the regext 01 version . . . . . . . . . 11 A.6. Change from the regext 01 to regext 02 version . . . . . 12 A.7. Change from the regext 02 to regext 03 version . . . . . 12 A.8. Change from the regext 03 to regext 04 version . . . . . 12 A.9. Change from the regext 04 to regext 05 version . . . . . 12 A.10. Change from the regext 05 to regext 06 version . . . . . 12 A.11. Change from the regext 06 to regext 07 version . . . . . 12 A.12. Change from the regext 07 to regext 08 version . . . . . 12 A.13. Change from the regext 08 to regext 09 version . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + A.14. Change from the regext 09 to regext 10 version . . . . . 13 + + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction [RFC6530] introduced the framework for Internationalized Email Addresses. To make such addresses more widely accepted, the changes to various protocols need to be introduced. This document describes an Extensible Provisioning Protocol (EPP) extension that permits usage of Internationalized Email Addresses in the EPP protocol and specifies the terms when it can be used by EPP @@ -383,25 +385,26 @@ Contact: jgould@verisign.com URL: https://www.verisign.com/en_US/channel-resources/domain- registry-products/epp-sdks 8. Security Considerations The extended security considerations discussion in [RFC6530] and [RFC6531] applies here. - As email address is often a primary end user contact, invalid email - address may put the communication with the end user into risk in case - when such contact is necessary. In case of invalid domain name a - malicious actor can register a valid domain with similar U-label - (homograph attack) and get a control over the domain using social + As email address is often a primary end user contact, an invalid + email address may put the communication with the end user into risk + in case when such contact is necessary. In case of an invalid domain + name in the email address a malicious actor can register a valid + domain name with similar U-label (homograph attack) and get a control + over the domain name associated with the contact using social engineering techniques. To reduce the risk of the use of invalid domain names in email addresses, registries SHOULD validate the domain name syntax in the provided email addresses and validate all code points in the domain name according to IDNA2008 [RFC5892]. 9. Acknowledgments The authors would like to thank Alexander Mayrhofer, Gustavo Lozano, Jody Kolker, John Levine, Klaus Malorny, Marco Schrieck, Mario Loffredo, Murray S. Kucherawy, Patrick Mevzek, Scott Hollenbeck, @@ -560,21 +563,26 @@ 3. Reference to RFC 7451 is moved to Informative. 4. IPR information is provided 5. Sections are reordered to align with the other regext documents A.13. Change from the regext 08 to regext 09 version 1. Nitpicking according to Murray S. Kucherawy review +A.14. Change from the regext 09 to regext 10 version + + 1. Some nitpicking in the security considerations. + Authors' Addresses + Dmitry Belyavskiy 8 marta st. Moscow 127083 Russian Federation Phone: +7 916 262 5593 Email: beldmit@gmail.com James Gould VeriSign, Inc.