idnits 2.17.1 draft-ietf-eppext-keyrelay-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2016) is 2885 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 eppext H.W. Ribbers 3 Internet-Draft M.W. Groeneweg 4 Intended status: Standards Track SIDN 5 Expires: December 2, 2016 R. Gieben 7 A.L.J Verschuren 9 May 31, 2016 11 Key Relay Mapping for the Extensible Provisioning Protocol 12 draft-ietf-eppext-keyrelay-12 14 Abstract 16 This document describes an Extensible Provisioning Protocol (EPP) 17 mapping for a key relay object that relays DNSSEC key material 18 between EPP clients using the poll queue defined in RFC5730. 20 This key relay mapping will help facilitate changing the DNS operator 21 of a domain while keeping the DNSSEC chain of trust intact. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 2, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 59 1.2. Secure Transfer of DNSSEC Key Material . . . . . . . . . 3 60 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. DNSSEC Key Material . . . . . . . . . . . . . . . . . . . 5 62 2.1.1. element . . . . . . . . . . . . . . . 5 63 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 66 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 6 67 3.1.3. EPP Command . . . . . . . . . . . . . . . 9 68 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 9 69 3.2.1. EPP Command . . . . . . . . . . . . . . . . 9 70 3.2.2. EPP Command . . . . . . . . . . . . . . . . 11 71 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 11 72 3.2.4. EPP Command . . . . . . . . . . . . . . . 12 73 3.2.5. EPP Command . . . . . . . . . . . . . . . . 12 74 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 13 77 5.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 13 78 5.3. EPP Extension Registry . . . . . . . . . . . . . . . . . 14 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 8.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 16 85 A.1. draft-gieben-epp-keyrelay-00 . . . . . . . . . . . . . . 16 86 A.2. draft-gieben-epp-keyrelay-01 . . . . . . . . . . . . . . 16 87 A.3. draft-gieben-epp-keyrelay-02 . . . . . . . . . . . . . . 16 88 A.4. draft-gieben-epp-keyrelay-03 . . . . . . . . . . . . . . 16 89 A.5. draft-ietf-eppext-keyrelay-00 . . . . . . . . . . . . . . 17 90 A.6. draft-ietf-eppext-keyrelay-01 . . . . . . . . . . . . . . 17 91 A.7. draft-ietf-eppext-keyrelay-02 . . . . . . . . . . . . . . 17 92 A.8. draft-ietf-eppext-keyrelay-03 . . . . . . . . . . . . . . 17 93 A.9. draft-ietf-eppext-keyrelay-04 . . . . . . . . . . . . . . 17 94 A.10. draft-ietf-eppext-keyrelay-05 . . . . . . . . . . . . . . 18 95 A.11. draft-ietf-eppext-keyrelay-06 . . . . . . . . . . . . . . 18 96 A.12. draft-ietf-eppext-keyrelay-07 . . . . . . . . . . . . . . 18 97 A.13. draft-ietf-eppext-keyrelay-08 . . . . . . . . . . . . . . 18 98 A.14. draft-ietf-eppext-keyrelay-09 . . . . . . . . . . . . . . 18 99 A.15. draft-ietf-eppext-keyrelay-10 . . . . . . . . . . . . . . 18 100 A.16. draft-ietf-eppext-keyrelay-11 . . . . . . . . . . . . . . 18 101 A.17. draft-ietf-regext-keyrelay-00 . . . . . . . . . . . . . . 18 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 104 1. Introduction 106 There are certain transactions initiated by a DNS-operator that 107 require an authenticated exchange of information between DNS- 108 operators. Often, there is no direct channel between these parties 109 or it is non-scalable and insecure. 111 One such transaction is the exchange of DNSSEC key material when 112 changing the DNS operator for DNSSEC signed zones. We suggest that 113 DNS-operators use the administrative EPP channel to bootstrap the 114 delegation by relaying DNSSEC key material for the zone. 116 In this document we define an EPP extension to sent DNSSEC key 117 material between EPP clients. This allows DNS operators to bootstrap 118 automatically, reliable and securely the transfer of a domain name 119 while keeping the DNSSEC chain of trust intact. 121 1.1. Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in BCP 14, RFC 2119 126 [RFC2119]. 128 XML is case sensitive. Unless stated otherwise, XML specifications 129 and examples provided in this document MUST be interpreted in the 130 character case presented in order to develop a conforming 131 implementation. 133 In examples, "C:" represents lines sent by a protocol client, and 134 "S:" represents lines returned by a protocol server. Indentation and 135 white space in examples is provided only to illustrate element 136 relationships and is not a mandatory feature of this protocol. 138 1.2. Secure Transfer of DNSSEC Key Material 140 Exchanging DNSSEC key material in preparation of a domain name 141 transfer is one of the phases in the lifecycle of a domain name 142 [I-D.koch-dnsop-dnssec-operator-change]. 144 DNS-operators need to exchange DNSSEC key material before the 145 registration data can be changed to keep the DNSSEC chain of trust 146 intact. This exchange is normally initiated through the gaining 147 registrar. 149 The gaining and losing DNS operators could talk directly to each 150 other (the ~ arrow in Figure 1) to exchange the DNSKEY, but often 151 there is no trusted path between the two. As both can securely 152 interact with the registry over the administrative channel through 153 the registrar, the registry can act as a relay for the key material 154 exchange. 156 The registry is merely used as a relay channel. Therefore it is up 157 to the losing DNS-operator to complete the intended transaction. The 158 registry SHOULD have certain policies in place that require the 159 losing DNS operator to cooperate with this transaction, however this 160 is beyond this document. This document focuses on the EPP protocol 161 syntax. 163 +--------------------+ DNSKEY +---------------------+ 164 |gaining DNS operator| ~~~~~~~~> | losing DNS operator | 165 +--------------------+ +---------------------+ 166 | ^ 167 | | 168 V | 169 +--------------------+ +---------------------+ 170 | gaining registrar | | registrar of record | 171 +--------------------+ +---------------------+ 172 | ^ 173 EPP keyrelay | | EPP poll 174 V | 175 +-----------------------------+ 176 | registry | 177 +-----------------------------+ 179 Figure 1: Transfer of DNSSEC key material. 181 There is no distinction in the EPP protocol between Registrars and 182 DNS-operators, there is only mention of an EPP client and EPP server. 183 Therefore the term EPP client will be used for the interaction with 184 the EPP server for relaying DNSSEC key material. 186 2. Object Attributes 187 2.1. DNSSEC Key Material 189 The DNSSEC key material is represented in EPP by a 190 element. 192 2.1.1. element 194 The contains the following elements: 196 o One REQUIRED element that contains the DNSSEC key 197 material as described in [RFC5910], Section 4 199 o An OPTIONAL element that describes the expected lifetime 200 of the relayed key(s) in the zone. When the element is 201 provided the losing DNS operator SHOULD remove the inserted key 202 material from the zone after the expire time. This may be because 203 the transaction that needed the insertion should either be 204 completed or abandoned by that time. If a client receives a key 205 relay object that has been sent previously it MUST update the 206 expire time of the key material. This enables the clients to 207 update the lifetime of the key material when a transfer is 208 delayed. 210 The element MUST contain exactly one of the following child 211 elements: 213 * : The DNSSEC key material is valid from the current 214 date and time until it expires on the specified date and time. If a 215 date in the past is provided this MUST be interpreted as a revocation 216 of a previously sent key relay object. 218 * : The DNSSEC key material is valid from the current date 219 and time until the end of the specified duration. If a period of 220 zero is provided this MUST be interpreted as a revocation of a 221 previously sent key relay object. 223 3. EPP Command Mapping 225 A detailed description of the EPP syntax and semantics can be found 226 in the EPP core protocol specification [RFC5730]. The command 227 mapping described here is specifically for use in this key relay 228 mapping. 230 3.1. EPP Query Commands 232 EPP provides three commands to retrieve object information: 233 to determine if an object is known to the server, to retrieve 234 detailed information associated with an object, and to 235 retrieve object transfer status information. 237 3.1.1. EPP Command 239 Check semantics do not apply to key relay objects, so there is no 240 mapping defined for the EPP command and the EPP 241 response. 243 3.1.2. EPP Command 245 Info command semantics do not apply to the key relay objects, so 246 there is no mapping defined for the EPP Command. 248 The EPP response for key relay objects is used in the EPP poll 249 response, as described in [RFC5730]. The key relay object created 250 with the command, described in Section 3.2.1 is inserted 251 into the receiving client's poll queue. The receiving client will 252 receive the key relay object using the EPP command, as 253 described in [RFC5730]. 255 When a command has been processed successfully for a key relay 256 poll message, the EPP element MUST contain a child 257 element that is identified by the keyrelay 258 namespace. The element contains the following 259 child elements: 261 o A REQUIRED element containing the domain name for which the 262 DNSSEC key material is relayed. 264 o A REQUIRED element that contains authorization 265 information associated with the domain object ([RFC5731], 266 Section 3.2.1). 268 o One or more REQUIRED elements containing data to be 269 relayed, as defined in Section 2.1. A server MAY apply a server 270 policy that specifies the number of elements that can 271 be incorporated. When a server policy is violated, a server MUST 272 respond with an EPP result code 2308 "Data management policy 273 violation". 275 o An OPTIONAL element that contains the date and time of the 276 submitted command. 278 o An OPTIONAL element that contains the identifier of the 279 client that requested the key relay. 281 o An OPTIONAL element that contains the identifier of the 282 client that SHOULD act upon the key relay. 284 Example response: 286 S: 287 S: 291 S: 292 S: 293 S: Command completed successfully; ack to dequeue 294 S: 295 S: 296 S: 1999-04-04T22:01:00.0Z 297 S: Keyrelay action completed successfully. 298 S: 299 S: 300 S: 301 S: example.org 302 S: 303 S: JnSdBAZSxxzJ 304 S: 305 S: 306 S: 307 S: 256 308 S: 3 309 S: 8 310 S: cmlraXN0aGViZXN0 311 S: 312 S: 313 S: P1M13D 314 S: 315 S: 316 S: 317 S: 1999-04-04T22:01:00.0Z 318 S: 319 S: 320 S: ClientX 321 S: 322 S: 323 S: ClientY 324 S: 325 S: 326 S: 327 S: 328 S: ABC-12345 329 S: 54321-ZYX 330 S: 331 S: 332 S: 334 3.1.3. EPP Command 336 Transfer semantics do not apply to key relay objects, so there is no 337 mapping defined for the EPP command. 339 3.2. EPP Transform Commands 341 EPP provides five commands to transform objects: to create 342 an instance of an object, to delete an instance of an 343 object, to extend the validity period of an object, 344 to manage object sponsorship changes, and to 345 change information associated with an object. 347 3.2.1. EPP Command 349 The EPP command provides a transform operation that allows a 350 client to create a key relay object that includes the domain name and 351 DNSSEC key material to be relayed. When the command is 352 validated, the server MUST insert an EPP message, using the 353 key relay info response (See Section 3.1.2), in the receiving 354 client's poll queue that belongs to the registrar on record of the 355 provided domain name. 357 In addition to the standard EPP command elements, the 358 command MUST contain a element that is identified 359 by the keyrelay namespace. The element contains 360 the following child elements: 362 o A REQUIRED element containing the domain name for 363 which the DNSSEC key material is relayed. 365 o A REQUIRED element that contains authorization 366 information associated with the domain object ([RFC5731], 367 Section 3.2.1). 369 o One or more REQUIRED element containing 370 data to be relayed, as defined in Section 2.1 372 Example commands: 374 Note that in the provided example the second 375 element has a period of zero and thus represents the revocation of a 376 previously sent key relay object (see Section 2.1.1). 378 C: 379 C: 383 C: 384 C: 385 C: 386 C: example.org 387 C: 388 C: JnSdBAZSxxzJ 389 C: 390 C: 391 C: 392 C: 256 393 C: 3 394 C: 8 395 C: cmlraXN0aGViZXN0 396 C: 397 C: 398 C: P1M13D 399 C: 400 C: 401 C: 402 C: 403 C: 256 404 C: 3 405 C: 8 406 C: bWFyY2lzdGhlYmVzdA== 407 C: 408 C: 409 C: P0D 410 C: 411 C: 412 C: 413 C: 414 C: ABC-12345 415 C: 416 C: 418 When a server has succesfully processed the command it MUST 419 respond with a standard EPP response. See [RFC5730], Section 2.6. 421 Example response: 423 S: 424 S: 425 S: 426 S: 427 S: Command completed successfully 428 S: 429 S: 430 S: ABC-12345 431 S: 54321-ZYX 432 S: 433 S: 434 S: 436 When a server cannot process the command due to the server 437 policy it MUST return an EPP 2308 error message. This might be the 438 case when the server knows that the receiving client does not support 439 keyrelay transactions. See [RFC5730], Section 2.6. 441 Example response: 443 S: 444 S: 445 S: 446 S: 447 S: Data management policy violation 448 S: 449 S: 450 S: ABC-12345 451 S: 54321-ZYX 452 S: 453 S: 454 S: 456 3.2.2. EPP Command 458 Delete semantics do not apply to key relay objects, so there is no 459 mapping defined for the EPP command and the EPP 460 response. 462 3.2.3. EPP Command 464 Renew semantics do not apply to key relay objects, so there is no 465 mapping defined for the EPP command and the EPP 466 response. 468 3.2.4. EPP Command 470 Transfer semantics do not apply to key relay objects, so there is no 471 mapping defined for the EPP command and the EPP 472 response. 474 3.2.5. EPP Command 476 Update semantics do not apply to key relay objects, so there is no 477 mapping defined for the EPP command and the EPP 478 response. 480 4. Formal Syntax 482 483 491 492 493 Extensible Provisioning Protocol v1.0 protocol 494 extension schema for relaying DNSSEC key material. 495 496 498 499 500 502 503 504 506 507 508 509 510 512 513 515 516 517 518 519 521 522 523 524 525 527 528 529 530 532 533 535 536 537 538 539 540 541 543 5. IANA Considerations 545 5.1. XML Namespace 547 This document uses URNs to describe a XML namespace conforming to the 548 registry mechanism described in [RFC3688]. The following URI 549 assignment is requested of IANA: 551 URI: urn:ietf:params:xml:ns:keyrelay-1.0 553 Registrant Contact: See the "Author's Address" section of this 554 document. 556 XML: See the "Formal Syntax" section of this document. 558 5.2. XML Schema 560 This document uses URNs to describe a XML schema conforming to the 561 registry mechanism described in [RFC3688]. The following URI 562 assignment is requested of IANA: 564 URI: urn:ietf:params:xml:schema:keyrelay-1.0 566 XML: See the "Formal Syntax" section of this document. 568 5.3. EPP Extension Registry 570 The EPP extension described in this document should be registered by 571 the IANA in the EPP Extension Registry described in [RFC7451]. The 572 details of the registration are as follows: 574 Name of Extension: "Key Relay Mapping for the Extensible Provisioning 575 Protocol" 577 Document status: Standards Track 579 Reference: (insert reference to RFC version of this document) 581 Registrant Name and Email Address: IESG, iesg@ietf.org 583 TLDs: Any 585 IPR Disclosure: https://datatracker.ietf.org/ipr/2393/ 587 Status: Active 589 Notes: None 591 6. Security Considerations 593 A server SHOULD NOT perform any transformation on data under server 594 management when processing a command. The intent 595 of this command is to put DNSSEC key material on the poll queue of 596 another client. To make sure that this EPP extension is 597 interoperable with the different server policies that already have 598 implemented EPP this extension it is not classified as must not. 600 Any EPP client can use this mechanism to put data on the message 601 queue of another EPP client, allowing for the potential of a denial 602 of service attack. However this can, and should be detected by the 603 server. A server MAY set a server policy which limits or rejects a 604 command if it detects the mechanism is being 605 abused. 607 For the data a correct 608 element should be used as an indication that putting the key material 609 on the receiving EPP clients poll queue is authorized by the 610 _registrant_ of that domain name. The authorization of EPP clients 611 to perform DNS changes is not covered in this document as it depends 612 on registry specific policy. 614 A client that uses this mechanism to send DNSSEC key material to 615 another client could verify through DNS that the DNSSEC key material 616 is added to the authoritive zone of the domain. This check can be 617 used to verify that the DNSSEC key material has traveled end-to-end 618 from the gaining DNS operator to the losing DNS operator. This check 619 does not tell anything about the DNSSEC chain of trust and can merely 620 be used as a verification of a succesful transfer of the DNSSEC key 621 material. 623 7. Acknowledgements 625 We like to thank the following individuals for their valuable input, 626 review, constructive criticism in earlier revisions or support for 627 the concepts described in this document: 629 Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal, 630 Patrik Faltstrom, Klaus Malorny, James Gould, Patrick Mevzek, Seth 631 Goldman, Maarten Bosteels, Ulrich Wisser, Kees Monshouwer and Scott 632 Hollenbeck. 634 8. References 636 8.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, March 1997. 641 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 642 January 2004. 644 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 645 STD 69, RFC 5730, August 2009. 647 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 648 Domain Name Mapping", STD 69, RFC 5731, August 2009. 650 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 651 Security Extensions Mapping for the Extensible 652 Provisioning Protocol (EPP)", RFC 5910, May 2010. 654 8.2. Informative References 656 [I-D.koch-dnsop-dnssec-operator-change] 657 Koch, P., Sanz, M., and A. Verschuren, "Changing DNS 658 Operators for DNSSEC signed Zones", draft-koch-dnsop- 659 dnssec-operator-change-06 (work in progress), February 660 2014. 662 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 663 Provisioning Protocol", RFC 7451, February 2015. 665 Appendix A. Changelog 667 [This section should be removed by the RFC editor before publishing] 669 A.1. draft-gieben-epp-keyrelay-00 671 1. Initial document. 673 A.2. draft-gieben-epp-keyrelay-01 675 1. Style and grammar changes; 677 2. Added an expire element as per suggestion by Klaus Malorny; 679 3. Make the authInfo element mandatory and make the registry check 680 it as per feedback by Klaus Malorny and James Gould. 682 A.3. draft-gieben-epp-keyrelay-02 684 1. Added element to identify the relaying EPP client as suggested by 685 Klaus Malorny; 687 2. Corrected XML for missing and excess clTRID as noted by Patrick 688 Mevzek; 690 3. Added clarifications for the examples based on feedback by 691 Patrick Mevzeck; 693 4. Reviewed the consistency of using DNS operator versus registrar 694 after review comments by Patrick Faltstrom and Ed Lewis. 696 A.4. draft-gieben-epp-keyrelay-03 698 1. Style and grammar changes 700 2. Corrected acknowledgement section 702 3. Corrected XML for Expire element to not be mandatory but only 703 occur once. 705 A.5. draft-ietf-eppext-keyrelay-00 707 1. Added feedback from Seth Goldman and put him in the 708 acknowledgement section. 710 2. IDnits formatting ajustments 712 A.6. draft-ietf-eppext-keyrelay-01 714 1. Introducing the command, and thus separating the data and 715 the command. 717 2. Updated the Introduction, describing the general use of relay vs 718 the intended use-case of relaying DNSSEC key data. 720 3. Restructuring the document to make it more inline with existing 721 EPP extensions. 723 A.7. draft-ietf-eppext-keyrelay-02 725 1. Updated the XML structure by removing the command based 726 on WG feedback 728 2. Updated the wording 730 A.8. draft-ietf-eppext-keyrelay-03 732 1. Updated the document title in the EPP Extension Registry section 734 2. Restored Acknowledgement section, thanks to Marco Davids 736 3. Incorperated feedback from Patrick Mevzek 738 A.9. draft-ietf-eppext-keyrelay-04 740 1. Incorperated feedback from James Gould 742 2. Added additional text when server is aware that receiving clients 743 do not support keyrelay transactions or DNSSEC as suggested by 744 Kees Monshouwer. 746 3. Added additional text for supporting key revocation as suggested 747 by Kees Monshouwer 749 4. Updated some of the wording 751 5. Fix the usage of multiple keys in a create message 753 A.10. draft-ietf-eppext-keyrelay-05 755 1. Review comments after WG last call 757 A.11. draft-ietf-eppext-keyrelay-06 759 1. Review comments by Ulrich Wisser during IESG writeup 761 A.12. draft-ietf-eppext-keyrelay-07 763 1. fixed changelog 765 A.13. draft-ietf-eppext-keyrelay-08 767 1. fixed issue with authinfo 769 2. fixed issue with relative period in example xml 771 A.14. draft-ietf-eppext-keyrelay-09 773 1. fixed issue with naming 775 A.15. draft-ietf-eppext-keyrelay-10 777 1. removed 4 spaces 779 A.16. draft-ietf-eppext-keyrelay-11 781 1. Processed editorial changes from AD review 783 2. Processed comments made during IETF last call 785 A.17. draft-ietf-regext-keyrelay-00 787 1. Processed comments made during IESG review 789 Authors' Addresses 791 Rik Ribbers 792 SIDN 793 Meander 501 794 Arnhem 6825 MD 795 NL 797 Email: rik.ribbers@sidn.nl 798 URI: https://www.sidn.nl/ 799 Marc Groeneweg 800 SIDN 801 Meander 501 802 Arnhem 6825 MD 803 NL 805 Email: marc.groeneweg@sidn.nl 806 URI: https://www.sidn.nl/ 808 Miek Gieben 810 Email: miek@miek.nl 812 Antoin Verschuren 814 Email: ietf@antoin.nl