idnits 2.17.1 draft-industrial-internet-identifier-data-escrow-05.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 -- Couldn't find a document date in the document -- date freshness check skipped. 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 21 2022 X. Fan 5 China Academy of Information and Communications Technology 6 June 16, 2022 7 Industrial Internet Identifier Node (IIIN) Data Escrow Specification 8 draft-industrial-internet-identifier-data-escrow-05 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 20, 2022. 42 Copyright Notice 44 Copyright (c) 2021 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 ............................................... 8 71 5.1. INDE Schema ............................................ 8 72 6. Internationalization Considerations......................... 12 73 7. Security Considerations..................................... 13 74 8. IANA Considerations ........................................ 13 75 9. Privacy Considerations...................................... 14 76 10. References ................................................ 14 77 10.1. Normative References.................................. 14 78 10.2. Informative References................................ 14 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 the 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 239 241 EXAMPLE2 243 245 247 249 Example of a Differential Deposit with the two example objects 250 indeObj1 and indeObj2: 252 254 264 2019-12-21T00:00:00Z 266 268 1.0 270 272 urn:ietf:params:xml:ns:indeObj1-1.0 274 276 278 urn:ietf:params:xml:ns:indeObj2-1.0 280 282 284 286 287 EXAMPLE1 289 291 293 EXAMPLE2 295 297 299 301 303 EXAMPLE3 305 307 309 EXAMPLE4 311 313 315 317 4.2. Child element 319 A REQUIRED element contains the data-time corresponding 320 to the Timeline Watermark of the deposit. 322 4.3. Child element 324 This element contains auxiliary information of the data escrow 325 deposit. A REQUIRED element contains the following child 326 elements: 328 o A REQUIRED element that identifies the INDE protocol 329 version. 331 o One or more elements that contain namespace URIs 332 representing the and element objects. 334 4.4. Child element 336 This element SHOULD be present in deposits of type Differential. It 337 contains the list of objects that were deleted since the base 338 previous deposit. Each object in this section SHALL contain an 339 identifier for the object deleted. 341 This section of the deposit SHOULD NOT be present in Full Deposits. 342 When rebuilding an IIIN it SHOULD be ignored if present in a Full 343 Deposit. 345 The specification for each object to be escrowed MUST declare the 346 identifier to be used to reference the object to be deleted. 348 4.5. Child element 350 This element of the deposit contains the objects in the deposit. It 351 MUST be present in all type of deposits. It contains the data for 352 the objects to be escrowed. The actual objects had to be specified 353 individually. 355 In the case of Differential Deposits, the objects indicate whether 356 the object was added or modified after the base previous deposit. In 357 order to distinguish between one and the other, it will be 358 sufficient to check existence of the reference object of the 359 previous deposit. 361 When applying Differential Deposits (when rebuilding the IIIN from 362 data escrow deposits) the relative order of the elements 363 is important, as is the relative order of the elements. 364 All the elements MUST be applied first, in the order that 365 they appear. All the elements MUST be applied next, in 366 the order that they appear. 368 If an object is present in the section of several 369 deposits (e.g. Full and Differential) the IIIN data from the latest 370 deposit (as defined by the Timeline Watermark) SHOULD be used when 371 rebuilding the IIIN. 373 5. Formal Syntax 375 5.1. INDE Schema 377 Copyright (c) 2019 IETF Trust and the persons identified as authors 378 of the code. All rights reserved. 380 Redistribution and use in source and binary forms, with or without 381 modification, are permitted provided that the following conditions 382 are met: 384 o Redistributions of source code must retain the above copyright 385 notice, this list of conditions and the following disclaimer. 387 o Redistributions in binary form must reproduce the above copyright 388 notice, this list of conditions and the following disclaimer in 389 the documentation and/or other materials provided with the 390 distribution. 392 o Neither the name of Internet Society, IETF or IETF Trust, nor the 393 names of specific contributors, may be used to endorse or promote 394 products derived from this software without specific prior 395 written permission. 397 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 398 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 399 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 400 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 401 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 402 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 403 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 404 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 405 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 406 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 407 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 408 POSSIBILITY OF SUCH DAMAGE. 410 BEGIN 412 414 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 467 469 471 473 475 477 478 480 482 484 486 488 490 492 494 496 498 500 502 504 506 508 510 512 514 518 520 522 524 526 527 529 531 533 535 537 539 541 543 545 547 549 551 553 555 557 559 561 563 565 567 569 END 571 6. Internationalization Considerations 573 Data escrow deposits are represented in XML, which provides native 574 support for encoding information using the Unicode character set and 575 its more compact representations including UTF-8. Conformant XML 576 processors recognize both UTF-8 and UTF-16. Though XML includes 577 provisions to identify and use other character encodings through use 578 of an "encoding" attribute in an declaration, use of UTF-8 579 is RECOMMENDED. 581 7. Security Considerations 583 This specification does not define the security mechanisms to be 584 used in the transmission of the data escrow deposits, since it only 585 specifies the minimum necessary to enable the rebuilding of an IIIN 586 from deposits without intervention from the original IIIN. 588 Depending on local policies, some elements or most likely, the whole 589 deposit will be considered confidential. As such the IIIN 590 transmitting the data to the escrow agent SHOULD take all the 591 necessary precautions like encrypting the data itself and/or the 592 transport channel to avoid inadvertent disclosure of private data. 594 It is also of the utmost importance the authentication of the 595 parties passing data escrow deposit files. The escrow agent SHOULD 596 properly authenticate the identity of the IIIN before accepting data 597 escrow deposits. In a similar manner, the IIIN SHOULD authenticate 598 the identity of the escrow agent before submitting any data. 600 Additionally, the IIIN and the escrow agent SHOULD use integrity 601 checking mechanisms to ensure the data transmitted is what the 602 source intended. Validation of the contents by the escrow agent is 603 RECOMMENDED to ensure not only the file was transmitted correctly 604 from the IIIN, but also the contents are also "meaningful". 606 8. IANA Considerations 608 This document uses URNs to describe XML namespaces and XML schemas 609 conforming to a registry mechanism described in [RFC3688]. Two URI 610 assignments need to be registered by the IANA. 612 Registration request for the INDE namespace: 614 URI: urn:ietf:params:xml:ns:inde-1.0 616 Registrant Contact: See the "Author's Address" section of this 617 document. 619 XML: None. Namespace URIs do not represent an XML specification. 621 Registration request for the INDE XML schema: 623 URI: urn:ietf:params:xml:schema:inde-1.0 625 Registrant Contact: See the "Author's Address" section of this 626 document. 628 XML: See the "Formal Syntax" section of this document. 630 9. Privacy Considerations 632 This specification defines a format that may be used to escrow 633 personal data. The process of data escrow is governed by a legal 634 document agreed by the parties, and such legal document must 635 regulate the particularities regarding the protection of personal 636 data. 638 10. References 640 10.1. Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 644 March 1997, . 645 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 646 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 647 . 648 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 649 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 650 May 2017, . 652 10.2. Informative References 654 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 655 DOI 10.17487/RFC3688, January 2004, 656 . 657 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 658 Architecture", RFC 4291, February 2006. 659 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 660 STD 69, RFC 5730, August 2009. 661 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support 662 IPv6 Address Aggregation and Renumbering", RFC 2874,July 663 2000. 664 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 665 "DNS Extensions to Support IP Version 6", RFC 3596, 666 October 2003. 668 11. Acknowledgments 670 This document reference draft [draft-ietf-regext-data-escrow-03], 671 thus, would like to thank the draft author G. Lozano. And would like 672 to thank X. Fan, J. Chen, C. Ma, M. Chen, Z. Li who provided special 673 important suggestions and invaluable comments. This document was 674 prepared using 2-Word-v2.0.template.dot. 676 Authors' Address 678 Hongjie Wu 679 CAICT 680 No.52 Huayuan North Road, Haidian District 681 Beijing, Beijing, 100191 682 China 684 Phone: +86 186 0106 5934 685 Email: wuhongjie@caict.ac.cn 687 Jian Chen 688 CAICT 689 No.52 Huayuan North Road, Haidian District 690 Beijing, Beijing, 100191 691 China 693 Phone: +86 138 1103 3332 694 Email: chenjian3@caict.ac.cn 696 Xiaotian Fan 697 CAICT 698 No.52 Huayuan North Road, Haidian District 699 Beijing, Beijing, 100191 700 China 702 Phone: +86 134 0108 6945 703 Email: fanxiaotian@caict.ac.cn 705 Menlan Chen 706 CAICT 707 No.52 Huayuan North Road, Haidian District 708 Beijing, Beijing, 100191 709 China 711 Phone: +86 139 1143 7301 712 Email: chenmeilan@caict.ac.cn 713 Zhiping Li 714 CAICT 715 No.52 Huayuan North Road, Haidian District 716 Beijing, Beijing, 100191 717 China 719 Phone: +86 185 1107 1386 720 Email: lizhiping@caict.ac.cn