draft-ietf-regext-secure-authinfo-transfer-02.txt		draft-ietf-regext-secure-authinfo-transfer-03.txt
	Network Working Group J. Gould		Network Working Group J. Gould
	Internet-Draft R. Wilhelm		Internet-Draft R. Wilhelm
	Intended status: Best Current Practice VeriSign, Inc.		Intended status: Best Current Practice VeriSign, Inc.
	Expires: December 14, 2020 June 12, 2020		Expires: February 1, 2021 July 31, 2020
	Extensible Provisioning Protocol (EPP) Secure Authorization Information		Extensible Provisioning Protocol (EPP) Secure Authorization Information
	for Transfer		for Transfer
	draft-ietf-regext-secure-authinfo-transfer-02		draft-ietf-regext-secure-authinfo-transfer-03
	Abstract		Abstract
	The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the		The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the
	use of authorization information to authorize a transfer. The		use of authorization information to authorize a transfer. The
	authorization information is object-specific and has been defined in		authorization information is object-specific and has been defined in
	the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact		the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact
	Mapping, in RFC 5733, as password-based authorization information.		Mapping, in RFC 5733, as password-based authorization information.
	Other authorization mechanisms can be used, but in practice the		Other authorization mechanisms can be used, but in practice the
	password-based authorization information has been used at the time of		password-based authorization information has been used at the time of
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 14, 2020.		This Internet-Draft will expire on February 1, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 9 ¶		skipping to change at page 3, line 9 ¶
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	11.1. Normative References . . . . . . . . . . . . . . . . . . 24		11.1. Normative References . . . . . . . . . . . . . . . . . . 24
	11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25		11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25		Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25
	A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 25		A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 25
	A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 25		A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 25
	A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 25		A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 25
	A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 27		A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 27
	A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 27		A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 27
	A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 27		A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 27
			A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the		The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the
	use of authorization information to authorize a transfer. The		use of authorization information to authorize a transfer. The
	authorization information is object-specific and has been defined in		authorization information is object-specific and has been defined in
	the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact		the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact
	Mapping, in [RFC5733], as password-based authorization information.		Mapping, in [RFC5733], as password-based authorization information.
	Other authorization mechanisms can be used, but in practice the		Other authorization mechanisms can be used, but in practice the
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 22 ¶
	registrar for each object and provides the mechanism (over EPP)		registrar for each object and provides the mechanism (over EPP)
	to coordinate a transfer of an object's sponsorship between		to coordinate a transfer of an object's sponsorship between
	registrars.		registrars.
	3. Signaling Client and Server Support		3. Signaling Client and Server Support
	This document does not define new protocol but a Best Current		This document does not define new protocol but a Best Current
	Practice (BCP) using the existing EPP protocol, where the client and		Practice (BCP) using the existing EPP protocol, where the client and
	the server can signal support for the BCP using a namespace URI in		the server can signal support for the BCP using a namespace URI in
	the login and greeting extension services. The namespace URI		the login and greeting extension services. The namespace URI
	"urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-0.1" is used		"urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0" is used to
	to signal support for the BCP. The client includes the namespace URI		signal support for the BCP. The client includes the namespace URI in
	in an <svcExtension> <extURI> element of the [RFC5730] <login>		an <svcExtension> <extURI> element of the [RFC5730] <login> Command.
	Command. The server includes the namespace URI in an <svcExtension>		The server includes the namespace URI in an <svcExtension> <extURI>
	<extURI> element of the [RFC5730] Greeting.		element of the [RFC5730] Greeting.
	A client that receives the namespace URI in the server's Greeting		A client that receives the namespace URI in the server's Greeting
	extension services, can expect the following supported behavior by		extension services, can expect the following supported behavior by
	the server:		the server:
	1. Support empty authorization information with a create command.		1. Support empty authorization information with a create command.
	2. Support unsetting authorization information with an update		2. Support unsetting authorization information with an update
	command.		command.
	3. Support validating authorization information with an info		3. Support validating authorization information with an info
	command.		command.
	skipping to change at page 20, line 47 ¶		skipping to change at page 20, line 47 ¶
	7.1. XML Namespace		7.1. XML Namespace
	This document uses URNs to describe XML namespaces conforming to a		This document uses URNs to describe XML namespaces conforming to a
	registry mechanism described in [RFC3688]. The following URI		registry mechanism described in [RFC3688]. The following URI
	assignment is requested of IANA:		assignment is requested of IANA:
	Registration request for the secure authorization information for		Registration request for the secure authorization information for
	transfer namespace:		transfer namespace:
	URI: urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-0.1		URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0
	Registrant Contact: IESG		Registrant Contact: IESG
	XML: None. Namespace URIs do not represent an XML specification.		XML: None. Namespace URIs do not represent an XML specification.
	7.2. EPP Extension Registry		7.2. EPP Extension Registry
	The EPP Best Current Practice (BCP) described in this document should		The EPP Best Current Practice (BCP) described in this document should
	be registered by the IANA in the EPP Extension Registry described in		be registered by the IANA in the EPP Extension Registry described in
	[RFC7451]. The details of the registration are as follows:		[RFC7451]. The details of the registration are as follows:
	Name of Extension: "Extensible Provisioning Protocol (EPP) Secure		Name of Extension: "Extensible Provisioning Protocol (EPP) Secure
	skipping to change at page 22, line 39 ¶		skipping to change at page 22, line 39 ¶
	Name: RegistryEngine EPP Service		Name: RegistryEngine EPP Service
	Description: Generic high-volume EPP service for gTLDs, ccTLDs and		Description: Generic high-volume EPP service for gTLDs, ccTLDs and
	SLDs		SLDs
	Level of maturity: Deployed in CentralNic's production environment as		Level of maturity: Deployed in CentralNic's production environment as
	well as two other gTLD registry systems, and two ccTLD registry		well as two other gTLD registry systems, and two ccTLD registry
	systems.		systems.
	Coverage: Auhtorization Information is "write only" in that the		Coverage: Authorization Information is "write only" in that the
	registrars can set the Auhtorization Information, but not get the		registrars can set the Authorization Information, but not get the
	Auhtorization Information in the Info Response.		Authorization Information in the Info Response.
	Licensing: Proprietary In-House software		Licensing: Proprietary In-House software
	Contact: epp@centralnic.com		Contact: epp@centralnic.com
	URL: https://www.centralnic.com		URL: https://www.centralnic.com
	9. Security Considerations		9. Security Considerations
	Section 4.1 defines the use a secure random value for the generation		Section 4.1 defines the use a secure random value for the generation
	skipping to change at page 27, line 30 ¶		skipping to change at page 27, line 30 ¶
	A.6. Change from REGEXT 01 to REGEXT 02		A.6. Change from REGEXT 01 to REGEXT 02
	1. Added inclusion of random salt for the hashed authorization		1. Added inclusion of random salt for the hashed authorization
	information, based on feedback from Ulrich Wisser.		information, based on feedback from Ulrich Wisser.
	2. Added clarification that the representation of a NULL (undefined)		2. Added clarification that the representation of a NULL (undefined)
	value is dependent on the type of database, based on feedback		value is dependent on the type of database, based on feedback
	from Patrick Mevzek.		from Patrick Mevzek.
	3. Filled in the Security Considerations section.		3. Filled in the Security Considerations section.
			A.7. Change from REGEXT 02 to REGEXT 03
			1. Updated the XML namespace to urn:ietf:params:xml:ns:epp:secure-
			authinfo-transfer-1.0, which removed bcp from the namespace and
			bumped the version from 0.1 and 1.0. Inclusion of bcp in the XML
			namespace was discussed at the REGEXT interim meeting.
			2. Replaced Auhtorization with Authorization based on a review by
			Jody Kolker.
	Authors' Addresses		Authors' Addresses
	James Gould		James Gould
	VeriSign, Inc.		VeriSign, Inc.
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	US		US
	Email: jgould@verisign.com		Email: jgould@verisign.com
	URI: http://www.verisign.com		URI: http://www.verisign.com
End of changes. 8 change blocks.
	12 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/