idnits 2.17.1 draft-industrial-internet-identifier-data-escrow-01.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 (June 22, 2020) is 1397 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- 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. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force H. Wu 2 Internet Draft Z. Li 3 Intended status: Experimental J. Chen 4 Expires: December 22 2020 X. Fan 5 China Academy of Information and Communications Technology 6 June 22, 2020 7 Industrial Internet Identifier Node (IIIN) Data Escrow Specification 8 draft-industrial-internet-identifier-data-escrow-01 10 Abstract 12 This document specifies the format and contents of data escrow 13 deposits targeted primarily for Industrial Internet Identifier Node 14 (IIIN) which provides identifier registration. However, this 15 specification was designed to be independent of the underlying 16 objects that are being escrowed, therefore it could be used for 17 purposes other than IIIN. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on December 22, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction ................................................ 2 60 2. Conventions used in this document............................ 3 61 3. General Conventions ......................................... 4 62 3.1. Date and Time .......................................... 4 63 3.2. IP Addresses ........................................... 4 64 4. Protocol Description......................................... 4 65 4.1. Root element .................................. 4 66 4.2. Child element ...............................7 67 4.3. Child element................................ 7 68 4.4. Child element................................. 8 69 4.5. Child element................................ 8 70 5. Formal Syntax ............................................... 9 71 5.1. INDE Schema ............................................ 9 72 6. Internationalization Considerations .........................13 73 7. Security Considerations..................................... 13 74 8. IANA Considerations ........................................ 14 75 9. Privacy Considerations...................................... 14 76 10. References ................................................ 14 77 10.1. Normative References.................................. 14 78 10.2. Informative References ................................15 79 11. Acknowledgments ........................................... 15 81 1. Introduction 83 Industrial Internet Identifier Node (IIIN) Data Escrow is the 84 process by which an IIIN periodically submits data deposits to a 85 third-party called an escrow agent. These deposits comprise the 86 minimum data needed by a third-party to resume operations if the 87 IIIN cannot function and is unable or unwilling to facilitate an 88 orderly transfer of service. For an IIIN, the data to be deposited 89 would include all the objects related to registered identifier. 91 The goal of data escrow is higher resiliency of registration 92 services, for the benefit of Internet users. The beneficiaries of an 93 IIIN are not just those registering information there, but all 94 relying parties that need to identify the owners of objects. 96 In the context of industry identifier namespace, data escrow is a 97 requirement for IIIN. There is also a similar requirement for IIIN 98 accredited identifier registration node. 100 This document specifies a format for data escrow deposits 101 independent of the objects being escrowed. A specification is 102 required for each type of registry/set of objects that is expected 103 to be escrowed. 105 2. Conventions used in this document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 Deposit. Deposits can be of two kinds: Full and Differential. For 114 all kinds of deposits, the universe of registry objects to be 115 considered for data escrow is those objects necessary in order to 116 offer the registry services. 118 Differential Deposit. Contains data that reflects all transactions 119 involving the database that were not reflected in the last previous 120 Full, or Differential Deposit, as the case may be. Differential 121 Deposit files will contain information from all database objects 122 that were added, modified or deleted since the previous deposit was 123 completed as of its defined Timeline Watermark. 125 Full Deposit. Contains the registry data that reflects the current 126 and complete registry database and will consist of data that 127 reflects the state of the IIIN as of a defined Timeline Watermark 128 for the deposit. 130 Escrow Agent. The organization designated by the IIIN or the third- 131 party beneficiary to receive and guard data escrow deposits from the 132 IIIN. 134 Third-Party Beneficiary. Is the organization that, under 135 extraordinary circumstances, would receive the escrow deposits the 136 IIIN transferred to the escrow agent. This organization could be a 137 backup IIIN, contracting party of the IIIN, etc. 139 Timeline Watermark. Point in time on which to base the collecting 140 of database objects for a deposit. Deposits are expected to be 141 consistent to that point in time. 143 3. General Conventions 145 The XML namespace prefix "inde" is used for the namespace 146 "urn:ietf:params:xml:ns:inde-1.0", but implementations MUST NOT 147 depend on it; instead, they should employ a proper namespace-aware 148 XML parser and serializer to interpret and output the XML documents. 150 The XML namespace prefix "indeObj1" and "indeObj2" with the 151 corresponding namespace "urn:ietf:params:xml:ns:indeObj1-1.0" and 152 "urn:ietf:params:xml:ns:indeObj2-1.0" are used as example data 153 escrow objects. 155 3.1. Date and Time 157 Numerous fields indicate "dates", such as the creation and expiry 158 dates for objects. These fields SHALL contain timestamp indicating 159 the date and time in UTC, specified in Internet Date/Time Format 160 (see [RFC3339], Section 5.6) with the time-offset specified as "Z". 162 3.2. IP Addresses 164 The syntax for IPv4 addresses described in this document MUST 165 conform to [RFC5730]. The syntax for IPv6 addresses described in 166 this document MUST conform to [RFC4291]. Practical considerations 167 for publishing IPv6 address information in zone files are documented 168 in [RFC2874] and [RFC3596]. A server MAY reject IP addresses that 169 have not been allocated for public use by IANA. 171 4. Protocol Description 173 The following is a format for data escrow deposits as produced by an 174 IIIN. The deposits are represented in XML. Only the format of the 175 objects deposited is defined, nothing is prescribed about the method 176 used to transfer such deposits between the IIIN and the escrow agent 177 or vice versa. 179 The protocol intends to be object agnostic allowing the "overload" 180 of abstract elements using the "substitutionGroup" attribute of the 181 XML Schema element to define the actual elements of an object to be 182 escrowed. 184 4.1. Root element 186 The container or root element for an IIIN Data Escrow deposit is 187 . This element contains the following child elements: 188 , , and elements. This 189 element also contains the following attributes: 191 o A REQUIRED "type" attribute that is used to identify the kind of 192 deposit: FULL (Full), or DIFF (Differential). 194 o A REQUIRED "id" attribute that is used to uniquely identify the 195 escrow deposit. Each IIIN is responsible for maintaining its own 196 escrow deposits identifier space to ensure uniqueness. 198 o An OPTIONAL "prevId" attribute that can be used to identify the 199 previous Differential or Full Deposit. This attribute MUST be 200 used in Differential Deposits ("DIFF" type). 202 o An OPTIONAL "resend" attribute that is incremented each time the 203 escrow deposit failed the verification procedure at the receiving 204 party and a new escrow deposit needs to be generated by the IIIN 205 for that specific date. The first time a deposit is generated the 206 attribute is either omitted or MUST be "0". If a deposit needs 207 to be generated again, the attribute MUST be set to "1", and so 208 on. 210 Example of a Full Deposit with two example objects indeObj1 and 211 indeObj2: 213 215 220 2019-12-20T00:00:00Z 222 224 1.0 226 urn:ietf:params:xml:ns:indeObj1-1.0 228 urn:ietf:params:xml:ns:indeObj2-1.0 230 232 234 236 EXAMPLE1 238 240 242 EXAMPLE2 244 246 248 250 Example of a Differential Deposit with two example objects indeObj1 251 and indeObj2: 253 255 265 2019-12-21T00:00:00Z 267 269 1.0 271 273 urn:ietf:params:xml:ns:indeObj1-1.0 275 277 279 urn:ietf:params:xml:ns:indeObj2-1.0 281 283 284 286 288 EXAMPLE1 290 292 294 EXAMPLE2 296 298 300 302 304 EXAMPLE3 306 308 310 EXAMPLE4 312 314 316 318 4.2. Child element 320 A REQUIRED element contains the data-time corresponding 321 to the Timeline Watermark of the deposit. 323 4.3. Child element 325 This element contains auxiliary information of the data escrow 326 deposit. A REQUIRED element contains the following child 327 elements: 329 o A REQUIRED element that identifies the INDE protocol 330 version. 332 o One or more elements that contain namespace URIs 333 representing the and element objects. 335 4.4. Child element 337 This element SHOULD be present in deposits of type Differential. It 338 contains the list of objects that were deleted since the base 339 previous deposit. Each object in this section SHALL contain an 340 identifier for the object deleted. 342 This section of the deposit SHOULD NOT be present in Full Deposits. 343 When rebuilding an IIIN it SHOULD be ignored if present in a Full 344 Deposit. 346 The specification for each object to be escrowed MUST declare the 347 identifier to be used to reference the object to be deleted. 349 4.5. Child element 351 This element of the deposit contains the objects in the deposit. It 352 MUST be present in all type of deposits. It contains the data for 353 the objects to be escrowed. The actual objects had to be specified 354 individually. 356 In the case of Differential Deposits, the objects indicate whether 357 the object was added or modified after the base previous deposit. In 358 order to distinguish between one and the other, it will be 359 sufficient to check existence of the reference object of the 360 previous deposit. 362 When applying Differential Deposits (when rebuilding the IIIN from 363 data escrow deposits) the relative order of the elements 364 is important, as is the relative order of the elements. 365 All the elements MUST be applied first, in the order that 366 they appear. All the elements MUST be applied next, in 367 the order that they appear. 369 If an object is present in the section of several 370 deposits (e.g. Full and Differential) the IIIN data from the latest 371 deposit (as defined by the Timeline Watermark) SHOULD be used when 372 rebuilding the IIIN. 374 5. Formal Syntax 376 5.1. INDE Schema 378 Copyright (c) 2020 IETF Trust and the persons identified as authors 379 of the code. All rights reserved. 381 Redistribution and use in source and binary forms, with or without 382 modification, are permitted provided that the following conditions 383 are met: 385 o Redistributions of source code must retain the above copyright 386 notice, this list of conditions and the following disclaimer. 388 o Redistributions in binary form must reproduce the above copyright 389 notice, this list of conditions and the following disclaimer in 390 the documentation and/or other materials provided with the 391 distribution. 393 o Neither the name of Internet Society, IETF or IETF Trust, nor the 394 names of specific contributors, may be used to endorse or promote 395 products derived from this software without specific prior 396 written permission. 398 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 399 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 400 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 401 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 402 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 403 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 404 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 405 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 406 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 407 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 408 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 409 POSSIBILITY OF SUCH DAMAGE. 411 BEGIN 413 415 422 424 426 Industrial Internet Identifier Node (IIIN) Data Escrow Schema 428 430 432 434 436 438 440 442 444 446 449 451 453 456 459 461 463 465 466 468 470 472 474 476 478 480 482 484 486 488 490 492 494 496 498 500 502 504 506 508 510 512 513 517 519 521 523 525 527 529 531 533 535 537 539 541 543 545 547 549 551 553 555 557 559 560 562 564 566 568 END 570 6. Internationalization Considerations 572 Data escrow deposits are represented in XML, which provides native 573 support for encoding information using the Unicode character set and 574 its more compact representations including UTF-8. Conformant XML 575 processors recognize both UTF-8 and UTF-16. Though XML includes 576 provisions to identify and use other character encodings through use 577 of an "encoding" attribute in an declaration, use of UTF-8 578 is RECOMMENDED. 580 7. Security Considerations 582 This specification does not define the security mechanisms to be 583 used in the transmission of the data escrow deposits, since it only 584 specifies the minimum necessary to enable the rebuilding of an IIIN 585 from deposits without intervention from the original IIIN. 587 Depending on local policies, some elements or most likely, the whole 588 deposit will be considered confidential. As such the IIIN 589 transmitting the data to the escrow agent SHOULD take all the 590 necessary precautions like encrypting the data itself and/or the 591 transport channel to avoid inadvertent disclosure of private data. 593 It is also of the utmost importance the authentication of the 594 parties passing data escrow deposit files. The escrow agent SHOULD 595 properly authenticate the identity of the IIIN before accepting data 596 escrow deposits. In a similar manner, the IIIN SHOULD authenticate 597 the identity of the escrow agent before submitting any data. 599 Additionally, the IIIN and the escrow agent SHOULD use integrity 600 checking mechanisms to ensure the data transmitted is what the 601 source intended. Validation of the contents by the escrow agent is 602 RECOMMENDED to ensure not only the file was transmitted correctly 603 from the IIIN, but also the contents are also "meaningful". 605 8. IANA Considerations 607 This document uses URNs to describe XML namespaces and XML schemas 608 conforming to a registry mechanism described in [RFC3688]. Two URI 609 assignments need to be registered by the IANA. 611 Registration request for the INDE namespace: 613 URI: urn:ietf:params:xml:ns:inde-1.0 615 Registrant Contact: See the "Author's Address" section of this 616 document. 618 XML: None. Namespace URIs do not represent an XML specification. 620 Registration request for the INDE XML schema: 622 URI: urn:ietf:params:xml:schema:inde-1.0 624 Registrant Contact: See the "Author's Address" section of this 625 document. 627 XML: See the "Formal Syntax" section of this document. 629 9. Privacy Considerations 631 This specification defines a format that may be used to escrow 632 personal data. The process of data escrow is governed by a legal 633 document agreed by the parties, and such legal document must 634 regulate the particularities regarding the protection of personal 635 data. 637 10. References 639 10.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 643 March 1997, . 644 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 645 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 646 . 647 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 648 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 649 May 2017, . 651 10.2. Informative References 653 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 654 DOI 10.17487/RFC3688, January 2004, 655 . 656 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 657 Architecture", RFC 4291, February 2006. 658 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 659 STD 69, RFC 5730, August 2009. 660 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support 661 IPv6 Address Aggregation and Renumbering", RFC 2874,July 662 2000. 663 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 664 "DNS Extensions to Support IP Version 6", RFC 3596, 665 October 2003. 666 11. Acknowledgments 668 This document reference draft [draft-ietf-regext-data-escrow-03], 669 thus, would like to thank the draft author G. Lozano. And would like 670 to thank X. Fan, J. Chen, C. Ma, M. Chen, Z. Li who provided special 671 important suggestions and invaluable comments. This document was 672 prepared using 2-Word-v2.0.template.dot. 674 Authors' Address 676 Hongjie Wu 677 CAICT 678 No.52 Huayuan North Road, Haidian District 679 Beijing, Beijing, 100191 680 China 682 Phone: +86 186 0106 5934 683 Email: wuhongjie@caict.ac.cn 685 Jian Chen 686 CAICT 687 No.52 Huayuan North Road, Haidian District 688 Beijing, Beijing, 100191 689 China 691 Phone: +86 138 1103 3332 692 Email: chenjian3@caict.ac.cn 693 Xiaotian Fan 694 CAICT 695 No.52 Huayuan North Road, Haidian District 696 Beijing, Beijing, 100191 697 China 699 Phone: +86 134 0108 6945 700 Email: fanxiaotian@caict.ac.cn 702 Meilan Chen 703 CAICT 704 No.52 Huayuan North Road, Haidian District 705 Beijing, Beijing, 100191 706 China 708 Phone: +86 139 1143 7301 709 Email: chenmeilan@caict.ac.cn 711 Zhiping Li 712 CAICT 713 No.52 Huayuan North Road, Haidian District 714 Beijing, Beijing, 100191 715 China 717 Phone: +86 185 1107 1386 718 Email: lizhiping@caict.ac.cn