idnits 2.17.1 draft-ietf-anima-voucher-00.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 == Line 452 has weird spacing: '...-reason enu...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 4, 2017) is 2668 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 (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track M. Richardson 5 Expires: July 8, 2017 SSW 6 M. Pritikin 7 Cisco Systems 8 T. Eckert 9 January 4, 2017 11 Voucher and Voucher Revocation Profiles for Bootstrapping Protocols 12 draft-ietf-anima-voucher-00 14 Abstract 16 This memo defines the two artifacts "voucher" and "voucher- 17 revocation", which are YANG-defined structures that have been signed 18 by a TBD algorithm. 20 The voucher artifact is generated by the device's manufacture or 21 delegate. The voucher's purpose is to securely assign one or more 22 devices to an owner. The voucher informs each device which entity it 23 should consider to be its owner. 25 The voucher revocation artifact is used by the manufacturer or 26 delegate (i.e. the issuer of the voucher) to revoke vouchers, if 27 ever necessary. The voucher revocation format defined herein 28 supports both issuer-wide and voucher-specific constructs, enabling 29 usage flexibility. 31 For both artifacts, this memo only defines the artifact, leaving it 32 to future work to describe specialized protocols for accessing them. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 8, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 69 3. Tree Diagram Notation . . . . . . . . . . . . . . . . . . . . 3 70 4. Voucher . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 72 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5 74 5. Voucher Revocation . . . . . . . . . . . . . . . . . . . . . 9 75 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 6.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 16 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16 82 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 9.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 This document defines a strategy to securely assign devices to an 93 owner, using an artifact signed, directly or indirectly, by the 94 device's manufacturer. This artifact is known as the voucher. 96 A voucher may be useful in several contexts, but the driving 97 motivation herein is to support secure bootstrapping mechanisms, such 98 as are defined in [draft-ietf-netconf-zerotouch] and 99 [draft-ietf-anima-bootstrapping-keyinfra]. Assigning ownership is 100 important to bootstrapping mechanisms so that the booting device can 101 authenticate the network that's trying to take control of it. 103 The lifetimes of vouchers may vary. In some bootstrapping protocols 104 the vouchers may be ephemeral, whereas in others the vouchers may be 105 potentially long-lived. In order to support the second category of 106 vouchers, this document also defines a voucher revocation artifact, 107 enabling the manufacturer or delegate to communicate the validity of 108 its vouchers. 110 For both artifacts, this memo only defines the artifact, leaving it 111 to future work to describe specialized protocols for accessing them. 113 This document uses YANG [RFC7950] to define the voucher and voucher 114 revocation formats. YANG is a data modeling language with 115 established mappings to XML and JSON, with mappings to other 116 encodings in progress. Which encodings a particular solution uses is 117 outside the scope of this document. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the 123 sections below are to be interpreted as described in RFC 2119 124 [RFC2119]. 126 3. Tree Diagram Notation 128 The meaning of the symbols in the above diagram is as follows: 130 o Brackets "[" and "]" enclose list keys. 132 o Braces "{" and "}" enclose feature names, and indicate that the 133 named feature must be present for the subtree to be present. 135 o Abbreviations before data node names: "rw" (read-write) represents 136 configuration data and "ro" (read-only) represents state data. 138 o Symbols after data node names: "?" means an optional node, "!" 139 means a presence container, and "*" denotes a list and leaf-list. 141 o Parentheses enclose choice and case nodes, and case nodes are also 142 marked with a colon (":"). 144 o Ellipsis ("...") stands for contents of subtrees that are not 145 shown. 147 4. Voucher 149 The voucher is generated by the device's manufacture or delegate. 150 The voucher's purpose is to securely assign one or more devices to an 151 owner. The voucher informs each device which entity it should 152 consider to be its owner. 154 The voucher is signed by the device's manufacturer or delegate. 155 NOTE: AT THIS TIME, THE SIGNING STRATEGY HAS NOT BEEN SELECTED. 157 4.1. Tree Diagram 159 Following is the tree diagram for the YANG module specified in 160 Section 4.3. Details regarding each node in the tree diagram are 161 provided in the YANG module. Please see Section 3 for information on 162 tree diagram notation. 164 module: ietf-voucher 165 +--ro voucher 166 +--ro assertion enumeration 167 +--ro trusted-ca-certificate? binary 168 +--ro certificate-id 169 | +--ro cn-id? string 170 | +--ro dns-id? string 171 +--ro unique-id* string 172 +--ro nonce? string 173 +--ro created-on? yang:date-and-time 174 +--ro expires-on? yang:date-and-time 175 +--ro revocation-location? inet:uri 176 +--ro additional-data? 178 4.2. Examples 180 The following illustrates an ephemeral voucher encoded in JSON: 182 { 183 "ietf-voucher:voucher": { 184 "assertion": "logged", 185 "trusted-ca-certificate": "base64-encoded X.509 DER", 186 "owner-id": "Registrar3245", 187 "unique-id": "JADA123456789", 188 "created-on": "2016-10-07T19:31:42Z", 189 "nonce": "987987623489567" 190 } 191 } 192 The following illustrates a long-lived voucher encoded in XML: 194 196 verified 197 198 base64-encoded X.509 DER 199 200 201 Example Inc. 202 example.com 203 204 AAA123456789 205 BBB123456789 206 CCC123456789 207 2016-10-07T19:31:42Z 208 210 4.3. YANG Module 212 file "ietf-voucher@2017-01-04.yang" 214 module ietf-voucher { 215 yang-version 1.1; 217 namespace 218 "urn:ietf:params:xml:ns:yang:ietf-voucher"; 219 prefix "vch"; 221 import ietf-yang-types { prefix yang; } 222 import ietf-inet-types { prefix inet; } 224 organization 225 "IETF ANIMA Working Group"; 227 contact 228 "WG Web: 229 WG List: 230 Author: Kent Watsen 231 232 Author: Max Pritikin 233 234 Author: Michael Richardson 235 "; 237 description 238 "This module defines the format for a voucher, which is 239 produced by a device's manufacturer or delegate to securely 240 assign one or more devices to an 'owner', so that the 241 devices may establish a secure connection to the owner's 242 network infrastructure."; 244 revision "2017-01-04" { 245 description 246 "Initial version"; 247 reference 248 "RFC XXXX: Voucher and Voucher Revocation Profiles 249 for Bootstrapping Protocols"; 250 } 252 // top-level container 253 container voucher { 254 config false; 255 description 256 "A voucher that can be used to assign one or more devices to 257 an owner."; 259 leaf assertion { 260 type enumeration { 261 enum verified { 262 description 263 "Indicates that the ownership has been positively 264 verified by the device's manufacturer or delegate 265 (e.g., through sales channel integration)."; 266 } 267 enum logged { 268 description 269 "Indicates that this ownership assignment has been 270 logged into a database maintained by the device's 271 manufacturer or delegate (voucher transparency)."; 272 } 273 } 274 mandatory true; 275 description 276 "The assertion is a statement from the manufacturer or 277 delegate regarding the nature of this voucher. This 278 allows the device to know what assurance the manufacturer 279 provides, which supports more detailed policy checks 280 such as 'I only want to allow verified devices, not 281 just logged devices'."; 282 } 284 leaf trusted-ca-certificate { 285 type binary; 286 description 287 "An X.509 v3 certificate structure as specified by RFC 5280, 288 Section 4 encoded using the ASN.1 distinguished encoding 289 rules (DER), as specified in ITU-T X.690. 291 This certificate is used by a bootstrapping device to 292 trust another public key infrastructure, in order to 293 verify another certificate supplied to the device 294 separately by the bootstrapping protocol, the other 295 certificate must have this certificate somewhere in 296 its chain of certificates."; 298 reference 299 "RFC 5280: 300 Internet X.509 Public Key Infrastructure Certificate 301 and Certificate Revocation List (CRL) Profile. 302 ITU-T X.690: 303 Information technology - ASN.1 encoding rules: 304 Specification of Basic Encoding Rules (BER), 305 Canonical Encoding Rules (CER) and Distinguished 306 Encoding Rules (DER)."; 307 } 309 container certificate-id { 310 description 311 "When provided, the device MUST also perform RFC 6125 312 style validation of another certificate supplied to 313 the device separately by the bootstrapping protocol 314 against all the provided ids."; 315 leaf cn-id { 316 type string; 317 description 318 "The common name field in the cetificate must match 319 this value."; 320 } 321 leaf dns-id { 322 type string; 323 description 324 "A subjectAltName entry of type dNSName in the 325 certificate must match this value."; 326 } 327 } 329 leaf-list unique-id { 330 type string; 331 min-elements 1; 332 description 333 "A regular expression identifying one more more device 334 unique identifiers (e.g., serial numbers). For instance, 335 the expression could match just a single serial number, 336 or it might match a range of serial numbers. Devices 337 use this value to determine if the voucher applies to 338 them."; 340 // Ed. both the zerotouch and brwski solutions are devid 341 // oriented, and so renaming this field to 'serial-number' 342 // wouldn't be crazy. But devid/serial-number (typically) 343 // assumes physical chassis, is it worth using this 344 // term which might extend to e.g. virtual appliances? 345 } 347 leaf nonce { 348 type string; // unit64? 349 description 350 "what can be said about this that's ANIMA-neutral?"; 351 } 353 leaf created-on { 354 type yang:date-and-time; 355 description 356 "The date this voucher was created"; 357 } 359 leaf expires-on { 360 type yang:date-and-time; 361 description 362 "An optional date value for when this voucher expires."; 363 } 365 leaf revocation-location { 366 type inet:uri; 367 description 368 "A URI indicating where revocation information may be 369 obtained."; 370 } 372 anydata additional-data { 373 description 374 "Additional data signed by the manufacturer. The manufacturer 375 might put additional data into its vouchers, for human or 376 device consumption."; 378 // Ed. is the additional data normative? - if so, should we 379 // remove this free-form field, and assume it will be formally 380 // extended later? Note: the zerotouch draft doesn't need this 381 // field... 382 } 383 } 385 } 387 389 5. Voucher Revocation 391 The vouchers revocation artifact is used to verify the revocation 392 status of vouchers. Voucher revocations are signed by the 393 manufacturer or delegate (i.e. the issuer of the voucher). Vouchers 394 revocation statements MAY be verified by devices during the 395 bootstrapping process, or at any time before or after by any entity 396 (e.g., registrar or equivalent) as needed. Registrars or equivalent 397 SHOULD verify voucher revocation statements and make policy decisions 398 in case devices are not doing so themselves. 400 Revocations are generally needed when it is critical for devices to 401 know that assurances implied at the time the voucher was signed are 402 still valid at the time the voucher is being processed. 404 As mentioned in Section 1, the lifetimes of vouchers may vary. In 405 some bootstrapping protocols the vouchers may be ephemeral, whereas 406 in others the vouchers may be potentially long-lived. For 407 bootstrapping protocols that support ephemeral vouchers, there is no 408 need to support revocations. For bootstrapping protocols that 409 support long-lived vouchers, the need to support revoking vouchers is 410 a decision for each manufacturer. 412 If revocations are not supported then voucher assignments are 413 essentially forever, which may be acceptable for various kinds of 414 devices. If revocations are supported, then it becomes possible to 415 support various scenarios such as handling a key compromise or change 416 in ownership. 418 The voucher revocation format defined herein supports both issuer- 419 wide (similar to a CRL) or voucher-specific (similar to an OCSP 420 response) constructs, enabling usage flexibility. 422 NOTE: AT THIS TIME, THE SIGNING STRATEGY HAS NOT BEEN SELECTED. 424 5.1. Tree Diagram 426 Following is the tree diagram for the YANG module specified in 427 Section 5.3. Details regarding each node in the tree diagram are 428 provided in the YANG module. Please see Section 3 for information on 429 tree diagram notation. 431 module: ietf-voucher-revocation 432 +--ro voucher-revocation 433 +--ro revocation-type enumeration 434 +--ro created-on yang:date-and-time 435 +--ro expires-on? yang:date-and-time 436 +--ro (voucher-revocation-type)? 437 | +--:(issuer-wide) 438 | | +--ro issuer-wide 439 | | +--ro (list-type)? 440 | | +--:(whitelist) 441 | | | +--ro whitelist 442 | | | +--ro voucher-identifier* string 443 | | +--:(blacklist) 444 | | +--ro blacklist 445 | | +--ro voucher-identifier* string 446 | +--:(voucher-specific) 447 | +--ro voucher-specific 448 | +--ro voucher-identifier string 449 | +--ro voucher-status enumeration 450 | +--ro revocation-information 451 | +--ro revoked-on yang:date-and-time 452 | +--ro revocation-reason enumeration 453 +--ro additional-data? 455 5.2. Examples 457 The following illustrates an issuer-wide voucher revocation in XML: 459 461 issuer-wide 462 2016-10-31T23:59:59Z 463 2016-12-31T23:59:59Z 464 465 466 some fingerprint 467 some fingerprint 468 some fingerprint 469 470 471 473 The following illustrates a voucher-specific revocation in JSON: 475 { 476 "ietf-voucher-revocation:voucher-revocation": { 477 "revocation-type": "voucher-specific", 478 "created-on": "2016-10-31T23:59:59Z" 479 "expires-on": "2016-12-31T23:59:59Z" 480 "voucher-specific": [ 481 "voucher-identifier": "some fingerprint", 482 "voucher-status": "revoked", 483 "revocation-information": [ 484 "revoked-on": "2016-11-31T23:59:59Z", 485 "revocation-reason": "key-compromise" 486 ] 487 ] 488 } 489 } 491 5.3. YANG Module 493 file "ietf-voucher-revocation@2017-01-04.yang" 495 module ietf-voucher-revocation { 496 yang-version 1.1; 498 namespace 499 "urn:ietf:params:xml:ns:yang:ietf-voucher-revocation"; 500 prefix "vr"; 502 import ietf-yang-types { prefix yang; } 504 organization 505 "IETF ANIMA Working Group"; 507 contact 508 "WG Web: 509 WG List: 510 Author: Kent Watsen 511 512 Author: Max Pritikin 513 514 Author: Michael Richardson 515 "; 517 description 518 "This module defines the format for a voucher revocation, 519 which is produced by a manufacturer or delegate to indicate 520 the revocation status of vouchers."; 522 revision "2017-01-04" { 523 description 524 "Initial version"; 525 reference 526 "RFC XXXX: Voucher and Voucher Revocation Profiles 527 for Bootstrapping Protocols"; 528 } 530 // top-level container 531 container voucher-revocation { 532 config false; 533 description 534 "A voucher revocation that can provide revocation status 535 information for one or more devices."; 537 leaf revocation-type { 538 type enumeration { 539 enum issuer-wide { 540 description 541 "Indicates that this revocation spans all 542 the vouchers the issuer has issued to date"; 543 } 544 enum voucher-specific { 545 description 546 "Indicated that this revocation only regards 547 a single voucher."; 548 } 549 } 550 mandatory true; 551 description 552 "The revocation-type indicates if the revocation 553 is issuer-wide or voucher-specific. Both variations 554 exist to enable implementations to choose between the 555 number of revocation artifacts generated versus 556 individual artifact size."; 557 } 559 leaf created-on { 560 type yang:date-and-time; 561 mandatory true; 562 description 563 "The date this voucher was created"; 564 } 566 leaf expires-on { 567 type yang:date-and-time; 568 description 569 "An optional date value for when this voucher expires."; 570 } 571 choice voucher-revocation-type { 572 description 573 "Identifies the revocation type as being either issuer-wide 574 or voucher-specific."; 576 container issuer-wide { 577 description 578 "This revocation provides issuer-wide revocation status 579 (similar to a CRL)."; 581 choice list-type { 582 description 583 "Indentifies if this issuer-wide revocation is provided 584 in the form of a whitelist or a blacklist"; 586 container whitelist { 587 leaf-list voucher-identifier { 588 type string; 589 description 590 "A fingerprint over the voucher artifact."; 591 } 592 description 593 "Indicates that the listed of vouchers are known 594 to be good. If a voucher is not listed, then 595 it is considered revoked."; 596 } 598 container blacklist { 599 leaf-list voucher-identifier { 600 type string; 601 description 602 "A fingerprint over the voucher artifact. 603 Missing if list is empty."; 604 } 605 description 606 "Indicates that the list of vouchers have been 607 revoked. If a voucher is not listed, then it 608 is considered good."; 609 } 611 } // end list-type 613 } // end issuer-wide 615 container voucher-specific { 616 description 617 "This revocation provides voucher-specific revocation 618 status (similar to an OCSP response)."; 620 leaf voucher-identifier { 621 type string; 622 mandatory true; 623 description 624 "A fingerprint over the voucher artifact."; 625 } 627 leaf voucher-status { 628 type enumeration { 629 enum good { 630 description 631 "Indicates that this voucher is valid"; 632 } 633 enum revoked { 634 description 635 "Indicates that this voucher is invalid"; 636 } 637 enum unknown { 638 description 639 "Indicates that the voucher's status is unknown"; 640 } 641 } 642 mandatory true; 643 description 644 "Indicates if the revocation status for the specified 645 voucher."; 646 } 648 container revocation-information { 649 must "../voucher-status = 'revoked'"; 651 leaf revoked-on { 652 type yang:date-and-time; 653 mandatory true; 654 description 655 "The date this voucher was revoked"; 656 } 658 leaf revocation-reason { 659 type enumeration { 660 enum unspecified { 661 description 662 "Indicates that the reason the voucher 663 was revoked is unspecified."; 664 } 665 enum key-compromise { 666 description 667 "Indicates that the reason the voucher 668 was revoked is because its key was 669 compromised."; 670 } 671 enum issuer-compromise { 672 description 673 "Indicates that the reason the voucher 674 was revoked is because its issuer was 675 compromised."; 676 } 677 enum affiliation-changed { 678 description 679 "Indicates that the reason the voucher 680 was revoked is because its affiliation 681 changed (e.g., device assigned to a 682 new owner."; 683 } 684 enum superseded { 685 description 686 "Indicates that the reason the voucher 687 was revoked is because it has been 688 superseded (e.g., the previous voucher 689 expired."; 690 } 691 enum cessation-of-operation { 692 description 693 "Indicates that the reason the voucher 694 was revoked is because its issuer has 695 ceased operations."; 696 } 697 } // end enumeration 699 mandatory true; 700 description 701 "modeled after 'CRLReason' in RFC 5280."; 702 } // end revocation reason 704 description 705 "Provides details regarding why a voucher's revocation. 706 Modeled after 'ResponseData' in RFC6960."; 708 } // end revocation-information 710 } // end voucher-specific 711 } 713 anydata additional-data { 714 description 715 "Additional data signed by the manufacturer. The manufacturer 716 might put additional data into its voucher revocations, for 717 human or device consumption."; 719 // Ed. is the additional data normative? - if so, should we 720 // remove this free-form field, and assume it will be formally 721 // extended later? Note: the zerotouch draft doesn't need this 722 // field... 723 } 725 } 726 } 728 730 6. Security Considerations 732 6.1. Clock Sensitivity 734 This document defines artifacts containing time values for voucher 735 expirations and revocations, which require an accurate clock in order 736 to be processed correctly. Implementations MUST ensure devices have 737 an accurate clock when shipped from manufacturing facilities, and 738 take steps to prevent clock tampering. 740 If it is not possible to ensure clock accuracy, it is RECOMMENDED 741 that implementations disable the aspects of the solution having clock 742 sensitivity. In particular, such implementations should assume that 743 vouchers neither ever expire or are revokable. 745 It is important to note that implementations SHOULD NOT rely on NTP 746 for time, as it is not a secure protocol. 748 7. IANA Considerations 750 7.1. The IETF XML Registry 752 This document registers two URIs in the IETF XML registry [RFC3688]. 753 Following the format in [RFC3688], the following registrations are 754 requested: 756 URI: urn:ietf:params:xml:ns:yang:ietf-voucher 757 Registrant Contact: The ANIMA WG of the IETF. 758 XML: N/A, the requested URI is an XML namespace. 760 URI: urn:ietf:params:xml:ns:yang:ietf-voucher-revocation 761 Registrant Contact: The ANIMA WG of the IETF. 762 XML: N/A, the requested URI is an XML namespace. 764 7.2. The YANG Module Names Registry 766 This document registers two YANG modules in the YANG Module Names 767 registry [RFC6020]. Following the format defined in [RFC6020], the 768 the following registrations are requested: 770 name: ietf-voucher 771 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher 772 prefix: vch 773 reference: RFC XXXX 775 name: ietf-voucher-revocation 776 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-revocation 777 prefix: vchr 778 reference: RFC XXXX 780 8. Acknowledgements 782 The authors would like to thank for following for lively discussions 783 on list and in the halls (ordered by last name): 785 9. References 787 9.1. Normative References 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, 791 DOI 10.17487/RFC2119, March 1997, 792 . 794 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 795 the Network Configuration Protocol (NETCONF)", RFC 6020, 796 DOI 10.17487/RFC6020, October 2010, 797 . 799 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 800 RFC 7950, DOI 10.17487/RFC7950, August 2016, 801 . 803 9.2. Informative References 805 [draft-ietf-anima-bootstrapping-keyinfra] 806 Pritikin, M., Richardson, M., Behringer, M., and S. 807 Bjarnason, "Bootstrapping Key Infrastructures", draft- 808 ietf-anima-bootstrapping-keyinfra (work in progress), 809 2016, . 812 [draft-ietf-netconf-zerotouch] 813 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 814 for NETCONF or RESTCONF based Management", draft-ietf- 815 netconf-zerotouch (work in progress), 2016, 816 . 819 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 820 DOI 10.17487/RFC3688, January 2004, 821 . 823 Appendix A. Change Log 825 Authors' Addresses 827 Kent Watsen 828 Juniper Networks 830 EMail: kwatsen@juniper.net 832 Michael C. Richardson 833 Sandelman Software Works 835 EMail: mcr+ietf@sandelman.ca 836 URI: http://www.sandelman.ca/ 838 Max Pritikin 839 Cisco Systems 841 EMail: pritikin@cisco.com 843 Toerless Eckert 845 EMail: tte+anima@cs.fau.de