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