draft-ietf-regext-verificationcode-03.txt   draft-ietf-regext-verificationcode-04.txt 
Network Working Group J. Gould Network Working Group J. Gould
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Intended status: Standards Track April 16, 2018 Intended status: Standards Track October 8, 2018
Expires: October 18, 2018 Expires: April 11, 2019
Verification Code Extension for the Extensible Provisioning Protocol Verification Code Extension for the Extensible Provisioning Protocol
(EPP) (EPP)
draft-ietf-regext-verificationcode-03 draft-ietf-regext-verificationcode-04
Abstract Abstract
This document describes an Extensible Provisioning Protocol (EPP) This document describes an Extensible Provisioning Protocol (EPP)
extension for including a verification code for marking the data for extension for including a verification code for marking the data for
a transform command as being verified by a 3rd party, which is a transform command as being verified by a 3rd party, which is
referred to as the Verification Service Provider (VSP). The referred to as the Verification Service Provider (VSP). The
verification code is digitally signed by the VSP using XML Signature verification code is digitally signed by the VSP using XML Signature
and is "base64" encoded. The XML Signature includes the VSP signer and is "base64" encoded. The XML Signature includes the VSP signer
certificate, so the server can verify that the verification code certificate, so the server can verify that the verification code
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 October 18, 2018. This Internet-Draft will expire on April 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 2, line 34 skipping to change at page 2, line 34
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 25 3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 25
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 27 3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 27
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 28 3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 28
3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 28 3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 28
3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 28 3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 28
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. Verification Code Extension Schema . . . . . . . . . . . 28 4.1. Verification Code Extension Schema . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 32 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 32
5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 32 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 32
6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 33
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 33
7.1. Normative References . . . . . . . . . . . . . . . . . . 33 6.2. Net::DRI . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2. Informative References . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . 35
B.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 34 8.2. Informative References . . . . . . . . . . . . . . . . . 36
B.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 35 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36
B.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 35 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 36
B.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 35 B.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 36
B.5. Change from 04 to REGEXT 00 . . . . . . . . . . . . . . . 35 B.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 36
B.6. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 35 B.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 36
B.7. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 35 B.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 36
B.8. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 35 B.5. Change from 04 to REGEXT 00 . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 B.6. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 37
B.7. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 37
B.8. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 37
B.9. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
This document describes an extension mapping for version 1.0 of the This document describes an extension mapping for version 1.0 of the
Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an
extension to EPP object mappings like the EPP domain name mapping extension to EPP object mappings like the EPP domain name mapping
[RFC5731], EPP host mapping [RFC5732], and EPP contact mapping [RFC5731], EPP host mapping [RFC5732], and EPP contact mapping
[RFC5733], can be used to pass a verification code to one of the EPP [RFC5733], can be used to pass a verification code to one of the EPP
transform commands. The domain name object is used for examples in transform commands. The domain name object is used for examples in
the document. The verification code is signed using XML Signature the document. The verification code is signed using XML Signature
skipping to change at page 3, line 28 skipping to change at page 3, line 30
The Verification Service Provider (VSP) is a certified party to The Verification Service Provider (VSP) is a certified party to
verify that data is in compliance with the policies of a locality. A verify that data is in compliance with the policies of a locality. A
locality MAY require the client to have data verified in accordance locality MAY require the client to have data verified in accordance
with local regulations or laws utilizing data sources not available with local regulations or laws utilizing data sources not available
to the server. The VSP has access to the local data sources and is to the server. The VSP has access to the local data sources and is
authorized to verify the data. Examples include verifying that the authorized to verify the data. Examples include verifying that the
domain name is not prohibited and verifying that the domain name domain name is not prohibited and verifying that the domain name
registrant is a valid individual, organization, or business in the registrant is a valid individual, organization, or business in the
locality. The data verified, and the objects and operations that locality. The data verified, and the objects and operations that
require the verification code to be passed to the server is up to the require the verification code to be passed to the server, is up to
policies of the locality. The verification code represents a marker the policies of the locality. The verification code represents a
that the verification was completed. The data verified by the VSP marker that the verification was completed. The VSP MUST store the
MUST be stored by the VSP along with the generated verification code proof of verification and the generated verification code; and MAY
to address any compliance issues. The signer certificate and the store the verified data. The signer certificate and the digital
digital signature of the verification code MUST be verified by the signature of the verification code MUST be verified by the server.
server.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "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.
XML is case sensitive. Unless stated otherwise, XML specifications XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the and examples provided in this document MUST be interpreted in the
character case presented in order to develop a conforming character case presented in order to develop a conforming
implementation. implementation.
In examples, "C:" represents lines sent by a protocol client and "S:" In examples, "C:" represents lines sent by a protocol client and "S:"
represents lines returned by a protocol server. Indentation and represents lines returned by a protocol server. Indentation and
white space in examples are provided only to illustrate element white space in examples are provided only to illustrate element
relationships and are not a REQUIRED feature of this protocol. relationships and are not a REQUIRED feature of this protocol.
skipping to change at page 33, line 8 skipping to change at page 33, line 8
Registrant Name and Email Address: IESG, <iesg@ietf.org> Registrant Name and Email Address: IESG, <iesg@ietf.org>
TLDs: Any TLDs: Any
IPR Disclosure: None IPR Disclosure: None
Status: Active Status: Active
Notes: None Notes: None
6. Security Considerations 6. Implementation Status
Note to RFC Editor: Please remove this section and the reference to
RFC 7942 [RFC7942] before publication.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942
[RFC7942]. The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations may exist.
According to RFC 7942 [RFC7942], "this will allow reviewers and
working groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this
information as they see fit".
6.1. Verisign EPP SDK
Organization: Verisign Inc.
Name: Verisign EPP SDK
Description: The Verisign EPP SDK includes both a full client
implementation and a full server stub implementation of draft-ietf-
regext-verificationcode.
Level of maturity: Production
Coverage: All aspects of the protocol are implemented.
Licensing: GNU Lesser General Public License
Contact: jgould@verisign.com
URL: https://www.verisign.com/en_US/channel-resources/domain-
registry-products/epp-sdks
6.2. Net::DRI
Organization: Dot and Co
Name: Net::DRI
Description: Net::DRI implements the client-side of draft-ietf-
regext-verificationcode.
Level of maturity: Production
Coverage: All client-side aspects of the protocol are implemented.
Licensing: GNU Lesser General Public License
Contact: netdri@dotandco.com
7. Security Considerations
The mapping extension described in this document is based on the The mapping extension described in this document is based on the
security services described by EPP [RFC5730] and protocol layers used security services described by EPP [RFC5730] and protocol layers used
by EPP. The security considerations described in these other by EPP. The security considerations described in these other
specifications apply to this specification as well. specifications apply to this specification as well.
XML Signature [W3C.CR-xmldsig-core2-20120124] is used in this XML Signature [W3C.CR-xmldsig-core2-20120124] is used in this
extension to verify that the Verification Code originated from a extension to verify that the Verification Code originated from a
trusted Verification Service Provider (VSP) and that it wasn't trusted Verification Service Provider (VSP) and that it wasn't
tampered with in transit from the VSP to the client to the server. tampered with in transit from the VSP to the client to the server.
skipping to change at page 33, line 33 skipping to change at page 34, line 49
It is RECOMMENDED that signed codes do not include white-spaces It is RECOMMENDED that signed codes do not include white-spaces
between the XML elements in order to mitigate risks of invalidating between the XML elements in order to mitigate risks of invalidating
the digital signature when transferring of signed codes between the digital signature when transferring of signed codes between
applications takes place. applications takes place.
Use of XML canonicalization SHOULD be used when generating the signed Use of XML canonicalization SHOULD be used when generating the signed
code. SHA256/RSA-SHA256 SHOULD be used for digesting and signing. code. SHA256/RSA-SHA256 SHOULD be used for digesting and signing.
The size of the RSA key SHOULD be at least 2048 bits. The size of the RSA key SHOULD be at least 2048 bits.
7. References The Verification Service Provider (VSP) MUST store the verification
data in compliance with the applicable privacy laws and regulations.
7.1. Normative References 8. References
8.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
skipping to change at page 34, line 27 skipping to change at page 35, line 45
editor.org/info/rfc5731>. editor.org/info/rfc5731>.
[RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
August 2009, <https://www.rfc-editor.org/info/rfc5732>. August 2009, <https://www.rfc-editor.org/info/rfc5732>.
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
August 2009, <https://www.rfc-editor.org/info/rfc5733>. August 2009, <https://www.rfc-editor.org/info/rfc5733>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[W3C.CR-xmldsig-core2-20120124] [W3C.CR-xmldsig-core2-20120124]
Cantor, S., Roessler, T., Eastlake, D., Yiu, K., Reagle, Cantor, S., Roessler, T., Eastlake, D., Yiu, K., Reagle,
J., Solo, D., Datta, P., and F. Hirsch, "XML Signature J., Solo, D., Datta, P., and F. Hirsch, "XML Signature
Syntax and Processing Version 2.0", World Wide Web Syntax and Processing Version 2.0", World Wide Web
Consortium CR CR-xmldsig-core2-20120124, January 2012, Consortium CR CR-xmldsig-core2-20120124, January 2012,
<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>. <http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.
7.2. Informative References 8.2. Informative References
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
February 2015, <https://www.rfc-editor.org/info/rfc7451>. February 2015, <https://www.rfc-editor.org/info/rfc7451>.
[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>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors wish to thank the following persons for their feedback
and suggestions:
o Gurshabad Grover
Appendix B. Change History Appendix B. Change History
B.1. Change from 00 to 01 B.1. Change from 00 to 01
1. Fixed pendingComplaince and complaint to pendingCompliance and 1. Fixed pendingComplaince and complaint to pendingCompliance and
compliant in text. compliant in text.
2. Fixed verificaton to verification. 2. Fixed verificaton to verification.
B.2. Change from 01 to 02 B.2. Change from 01 to 02
skipping to change at page 35, line 37 skipping to change at page 37, line 24
B.7. Change from REGEXT 01 to REGEXT 02 B.7. Change from REGEXT 01 to REGEXT 02
1. Ping update. 1. Ping update.
B.8. Change from REGEXT 02 to REGEXT 03 B.8. Change from REGEXT 02 to REGEXT 03
1. Moved RFC 7451 to an informational reference based on a check 1. Moved RFC 7451 to an informational reference based on a check
done by the Idnits Tool. done by the Idnits Tool.
2. Replaced the IANA Registrant Contact to be "IESG". 2. Replaced the IANA Registrant Contact to be "IESG".
B.9. Change from REGEXT 03 to REGEXT 04
1. Added the Implementation Status section.
2. Revised the sentence "The data verified by the VSP MUST be stored
by the VSP along with the generated verification code to address
any compliance issues." to "The VSP MUST store the proof of
verification and the generated verification code; and MAY store
the verified data.", and added text to the Security
Considerations section associated with storing the verification
data, based on feedback from Gurshabad Grover.
Author's Address Author's Address
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. 14 change blocks. 
32 lines changed or deleted 128 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/