idnits 2.17.1 draft-ietf-anima-voucher-delegation-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 == Line 323 has weird spacing: '...ndatory false...' -- The document date (14 June 2021) is 1040 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) == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-10 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 M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track W. Pan 5 Expires: 16 December 2021 Huawei Technologies 6 14 June 2021 8 Delegated Authority for Bootstrap Voucher Artifacts 9 draft-ietf-anima-voucher-delegation-01 11 Abstract 13 This document describes an extension of the RFC8366 Voucher Artifact 14 in order to support delegation of signing authority. The initial 15 voucher pins a public identity, and that public indentity can then 16 issue additional vouchers. This chain of authorization can support 17 permission-less resale of devices, as well as guarding against 18 business failure of the BRSKI Manufacturer Authorized Signing 19 Authority (MASA). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 16 December 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements for the Delegation . . . . . . . . . . . . . 3 56 1.1.1. Device Onboarding with Disconnected or Offline 57 MASA . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1.2. Resale of Devices . . . . . . . . . . . . . . . . . . 3 59 1.1.3. Crypto-agility for Registrar . . . . . . . . . . . . 4 60 1.1.4. Transparent Assemblers/Value-Added-Resellers . . . . 4 61 1.2. Overview of Proposed Solution . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Delegation Voucher Artifact . . . . . . . . . . . . . . . . . 5 64 3.1. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Bundling of The Vouchers . . . . . . . . . . . . . . . . 9 66 3.3. Delegation of Multiple Devices . . . . . . . . . . . . . 9 67 4. Enhanced Pledge Behavior . . . . . . . . . . . . . . . . . . 9 68 5. Changes to Registrar Behavior . . . . . . . . . . . . . . . . 10 69 5.1. Discovering The Most Recent Delegated Authority to Use . 10 70 6. Applying The Delegation Voucher to Requirements . . . . . . . 11 71 6.1. Case 1: Resale . . . . . . . . . . . . . . . . . . . . . 11 72 6.2. Case 2: Assembly . . . . . . . . . . . . . . . . . . . . 13 73 7. Constraints on Pinning The Delegated Authority . . . . . . . 13 74 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 9.1. Delegation Vouchers do not expire . . . . . . . . . . . . 13 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 14 79 10.2. YANG Module Names Registry . . . . . . . . . . . . . . . 14 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 81 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 13.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Appendix A. Extra references . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 The [RFC8366] voucher artifact provides a proof from a manufacturer's 91 authorizing signing authority (MASA) of the intended owner of a 92 device. This is used by an onboarding Pledge device in BRSKI 93 ([RFC8995], [I-D.ietf-anima-constrained-voucher]), and SZTP 94 ([RFC8572]). 96 There are a number of criticisms of the MASA concept. They include: 98 * the MASA must be reachable to the Registar during the onboarding 99 process. 101 * while the use of a nonceless voucher (see [RFC8366] section 4) can 102 permit the MASA to be offline, it still requires the public key/ 103 certificate of the Registrar to be known at issuing time. The 104 device owner is always strongly dependent on the MASA service. 106 * the MASA must approve all transfers of ownership, impacting the 107 rights of the supply chain distributors to transfer ownership as 108 they see fit. 110 * if the Registrar has any nonceless vouchers, then it can not 111 change it's public key, nor can it change which certification 112 authority it uses. 114 * it is not possible for a MASA to pin ownership to a Registrar by 115 Certification Authority plus DN. 117 * the creator of an assembly of parts/components can speak for the 118 entire assembly of parts in a transparent way. 120 1.1. Requirements for the Delegation 122 This voucher artifact satisfies the following requirements: 124 1.1.1. Device Onboarding with Disconnected or Offline MASA 126 A Registrar wishes to onboard devices while it is not being connected 127 to the Internet and MASA. 129 1.1.2. Resale of Devices 131 An owner of a device wishes to resale it which has previously been 132 onboarded to a third party without specific authorization from the 133 manufacturer. 135 1.1.3. Crypto-agility for Registrar 137 The owner/manager of a registrar wishes to be able to replace its 138 domain registration key. Replacing the registration key would 139 invalidate any previously acquired (nonceless) vouchers. Any devices 140 which have not been onboarded, or which need to be factory reset, 141 would not trust a replacement key. 143 1.1.4. Transparent Assemblers/Value-Added-Resellers 145 An assembly may consist of a number of parts which are onboarded to a 146 local controller during the manufacturing process. Subsequent to 147 this, the entire assembly will be shipped to a customer who wishes to 148 onboard all the components. The sub-components of the assembly needs 149 to communicate with other sub-components, and so all the parts need 150 to transparently onboarded. (This is contrasted with an assembly 151 where the controller acts as a security gateway. Such a gateway 152 might be a single point of failure) 154 Assemblies may nest quite deeply. 156 1.2. Overview of Proposed Solution 158 The MASA will issue a voucher that delegates it's signing authority 159 for one or more devices to a specific Registrar. This is called a 160 "delegation voucher". 162 This Registrar can then operate as an authorized signing authority 163 for the manufacturer, and can subsequently issue additional vouchers 164 binding the pledge to new Registrars. 166 This delegation can potentially be repeated multiple times to enable 167 second, third, or n-th level of resale. 169 The delegation voucher may be stored by the pledge for storage, to be 170 included by the pledge in subsequent bootstrap operations. The 171 inclusion of the delegation voucher permits next Registrar with 172 heuristics that permit it to find the delegated authorized signing 173 authority (DASA). 175 The delegation voucher pins the identity of the delegated authority 176 using a variety of different mechanisms which are covered in 177 Section 7. 179 2. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in 184 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 185 capitals, as shown here. 187 Delegated Authorized Signing Authority : the Delegated Authorized 188 Signing Authority (DASA) is a service that can generate vouchers 189 for one or more pledges to provide bootstrap authority, which is 190 separated and delegated from the manufacturer. 192 Delegation Voucher: a Delegation Voucher is an [RFC8366] format 193 voucher that has additional fields to provide details of the 194 entity to which authority has been delegated. 196 Intermediate Voucher: a voucher that is not the final voucher 197 linking a pledge to its owner. 199 End Voucher: a voucher that is the final voucher linking a pledge to 200 its owner. 202 3. Delegation Voucher Artifact 204 The following tree diagram shows the extensions to the [RFC8366] 205 voucher. 207 There are a few new fields: 209 delegation-enable-flag: A global enable flag to the pledge that it 210 can be delegated (true) or not (false). With default, this flag 211 is false, which is consistent with the voucher artifact in 212 RFC8366. 214 pinned-delegation-cert-authority: An subject-public-key-info for a 215 public key of the new DASA 217 pinned-delegation-cert-name: A string for the rfc822Name 218 SubjectAltName contents of the new DASA; (XXX- is it enough, 219 should other DNs be considered?) 221 delegation-voucher: One or a series of Intermediate Vouchers that 222 delegate authority to the DASA. For the latter case, the series 223 of Intermediate Vouchers constitute a nested structure, and the 224 most inner voucher is from the MASA, which is called terminal 225 voucher here 227 intermediate-identities: A set of voucher identities being 228 consistent with the series of Intermediate Vouchers 230 delegation-countdown: Number of delegations still available. If 231 zero or omitted, then this is a terminal voucher and may not be 232 further delegated. 234 In addition, the serial-number field is no longer a plain leaf, but 235 can also be an array (See Section 3.3). 237 module: ietf-voucher-delegated 239 grouping voucher-delegated-grouping 240 +-- voucher 241 +-- created-on yang:date-and-time 242 +-- expires-on? yang:date-and-time 243 +-- assertion enumeration 244 +-- serial-number string 245 +-- idevid-issuer? binary 246 +-- pinned-domain-cert? binary 247 +-- domain-cert-revocation-checks? boolean 248 +-- nonce? binary 249 +-- last-renewal-date? yang:date-and-time 250 +-- delegation-enable-flag? boolean 251 +-- pinned-delegation-cert-authority? binary 252 +-- pinned-delegation-cert-name? binary 253 +-- delegation-voucher? binary 254 +-- intermediate-identities? binary 255 +-- delegation-countdown? int16 257 3.1. YANG Module 259 This module uses the grouping that was created in [RFC8366] to extend 260 the definition. 262 file "ietf-voucher-delegated@2020-01-06.yang" 263 module ietf-voucher-delegated { 264 yang-version 1.1; 266 namespace 267 "urn:ietf:params:xml:ns:yang:ietf-voucher-delegated"; 268 prefix "delegated"; 270 import ietf-restconf { 271 prefix rc; 272 description 273 "This import statement is only present to access 274 the yang-data extension defined in RFC 8040."; 276 reference "RFC 8040: RESTCONF Protocol"; 277 } 279 // maybe should import from constrained-voucher instead! 280 import ietf-voucher { 281 prefix "v"; 282 } 284 organization 285 "IETF ANIMA Working Group"; 287 contact 288 "WG Web: 289 WG List: 290 Author: Michael Richardson 291 "; 293 description 294 "This module extends the RFC8366 voucher format to provide 295 a mechanism by which the authority to issue additional vouchers 296 may be delegated to another entity 298 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 299 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 300 and 'OPTIONAL' in the module text are to be interpreted as 301 described in BCP 14 RFC 2119, and RFC8174."; 303 revision "2020-01-06" { 304 description 305 "Initial version"; 306 reference 307 "RFC XXXX: Voucher Profile for Delegation Vouchers"; 308 } 310 rc:yang-data voucher-delegated-artifact { 311 // YANG data template for a voucher. 312 uses voucher-delegated-grouping; 313 } 315 // Grouping defined for future usage 316 grouping voucher-delegated-grouping { 317 description 318 "Grouping to allow reuse/extensions in future work."; 320 uses v:voucher-artifact-grouping { 322 refine voucher/pinned-domain-cert { 323 mandatory false; 325 } 327 augment "voucher" { 328 description "Base the delegated voucher 329 upon the regular one"; 331 leaf delegation-enable-flag { 332 type boolean; 333 description 334 "A global enable flag to the pledge that it can be 335 delegated (true) or not (false). With default, 336 this flag is false, which is consistent with 337 the voucher artifact in RFC8366. "; 338 } 340 leaf pinned-delegation-cert-authority { 341 type binary; 342 description 343 "An subject-public-key-info for a public key of the 344 certificate authority that is to be trusted to issue 345 a delegation voucher to the Registrar. 346 This is not used by end-vouchers, and only valid 347 when delegation-enable-flag is true."; 348 } 350 leaf pinned-delegation-cert-name { 351 type binary; 352 description 353 "A string for the rfc822Name SubjectAltName contents 354 which will be trusted to issue delegation vouchers. 355 This is not used by end-vouchers, and only valid 356 when delegation-enable-flag is true."; 357 } 359 leaf delegation-voucher { 360 type binary; 361 description 362 "The intermediate voucher that delegates 363 authority to the entity that signs this voucher 364 is to be included here, and only valid 365 when delegation-enable-flag is true."; 366 } 368 leaf intermediate-identities { 369 type binary; 370 description 371 "A set of identities that will be needed to 372 validate the chain of vouchers, and only valid 373 when delegation-enable-flag is true. MAY BE REDUNDANT"; 374 } 376 leaf delegation-countdown { 377 type int16; 378 description 379 "Number of delegations still available, and only valid 380 when delegation-enable-flag is true. If zero 381 or omitted, then this is a terminal voucher and 382 may not be further delegated"; 383 } 384 } 385 } 386 } 387 } 388 390 3.2. Bundling of The Vouchers 392 [RFC8995] defines a mechanism to return a single voucher to the 393 pledge. 395 This protocol requires a number of additional items to be returned to 396 the pledge for evaluation: the series of Intermediate Vouchers that 397 leads to the DASA, and the public keys (often as certificates) of the 398 Registrars on the Delegation Path that leads to each Authority. 400 3.3. Delegation of Multiple Devices 402 A MASA MAY delegate multiple devices to the same Registrar by putting 403 an array of items in the "serial-number" attributes. (XXX-how to 404 describe this in the YANG, and the detailed mechanism, are TBD) 406 4. Enhanced Pledge Behavior 408 The use of a Delegation Voucher requires changes to how the pledge 409 evaluates the voucher that is returned to by the Registrar. 411 There are no significant changes to the voucher-request that is made. 412 The pledge continues to pin the identity of the Registrar to which it 413 is connected, providing a nonce to establish freshness. 415 A pledge which has previously stored a Delegation Voucher and DASA , 416 SHOULD include it in its voucher request. This will be in the form 417 of a certificate provided by the "previous" owner. This allows the 418 Registrar to discover the previous authority for the pledge. As the 419 pledge has no idea if it connecting to an entity that it previously 420 has connected to, it needs to include this certificate anyway. 422 The pledge receives a voucher from the Registrar. This voucher is 423 called the zero voucher. It will observe that the voucher is not 424 signed with its built-in manufacturer trust anchor and it can not 425 verify it. 427 The pledge will examine the voucher to look for the "delegation- 428 voucher" and the "intermediate-identities" attributes within the 429 voucher. A certificate from the set of intermediate-identities is 430 expected to validate the signature on this zeroth end-entity voucher. 431 (XXX- This attribute can be replaced by the CMS certificate chain) 433 The contained delegation-voucher object is to be interpreted as an 434 (Intermediate) Voucher. This first voucher is called the first 435 voucher, or "voucher[1]". Generically, for voucher[i], the voucher 436 found in the delegation-voucher is called voucher[i+1]. 438 If voucher[i] can be validated by a built-in trust anchor, then the 439 process is done. If not, then voucher[i] is examined in a recursive 440 process until there are no further embedded vouchers. The last 441 voucher[n] is expected to be validated by a built-in manufacturer 442 trust anchor. 444 Once the top (n-th) voucher is found, then the pinned-certificate- 445 authority is added to the working set of trust anchors. The "pinned- 446 certificate-name" attribute is used along with the trust anchor to 447 validate the certificate chain provided with the (n-1)th voucher. 448 This is repeated (unwinding the recursive processing) until the 449 zeroth voucher has been validated. 451 5. Changes to Registrar Behavior 453 The Registrar is the component that authenticates the pledge, makes 454 authorization decisions, and distributes vouchers. If the vouchers 455 is delegated, then the registrar need to co-ordinate MASA and DASA. 457 5.1. Discovering The Most Recent Delegated Authority to Use 459 The pledge continues to use its manufacturer issued IDevID when 460 performing BRSKI-style onboarding. The IDevID contains an extension, 461 the MASA URL (see [RFC8995] section 2.3.2). The IDevID certificate 462 is not expected to be updated when the device is resold, nor may it 463 be practical for an intermediate owner to be able to replace the 464 IDevID with their own. (Some devices may support having an 465 intermediate owner replace the IDevID, in which case this section 466 does not apply) 467 The Registrar needs to be informed that it should not contact a MASA 468 using the URL in the IDevID, but rather to contact the previous 469 owner's DASA. 471 This can be accomplished by local override, as described in [RFC8995] 472 section 5.4: 474 Registrars MAY include a mechanism to override 475 the MASA URL on a manufacturer-by-manufacturer basis, and within that 476 override it is appropriate to provide alternate anchors. This will 477 typically used by some vendors to establish explicit (or private) 478 trust anchors for validating their MASA that is part of a sales 479 channel integration. 481 The above override needs to be established on a per-device basis. It 482 requires per-device configuration which is very much non-autonomic. 484 There are two other alternatives: 486 1. The Manufacturer could be aware of any Delegation Vouchers that 487 it has issued for a particular device, and when contacted by the 488 Registrar, it could redirect the Registrar to its DASA. And the 489 DASA may redirect the Registrar to its delegated DASA, this 490 process is recursive to the final DASA. 492 2. The Pledge could provide a signed statement from the manufacturer 493 providing the Registrar with a pointer to the DASA. 495 Option 1 requires that the Registrar still contact the MASA, 496 violating most of the goals from Section 1.1. 498 Option 2 requires a signed artifact, and conveniently, the Delegation 499 Voucher is exactly the item needed. The most difficult problem is 500 that the Pledge needs to (a) store one or more Delegation Vouchers in 501 a non-volatile storage that survives factory reset operations, (b) 502 attach these items to the pledge's voucher-request. 504 The extension to the [RFC8995] voucher-request described below 505 provides for a contained for these Delegation Vouchers. 507 6. Applying The Delegation Voucher to Requirements 509 6.1. Case 1: Resale 511 This case has many application scenarios. 513 The simplest is that a device, previously owned by one entity is sold 514 to another entity. This would include many large home appliances 515 (furnace, stove, refriderator) which are either sold with the home 516 (because they are attached), or for which there is a frequent resale 517 market. Entire systems (HVAC, physical security, elevators) in 518 commercial buildings also fall into this category. Many of these 519 devices exist for decades. 521 The initial onboarder would obtain a delegated voucher, and would 522 keep this voucher safe. Should the device need to be resold, this 523 voucher is provided to the new owner. This protects the first owner 524 from situations where the manufacturer is unwilling, or goes into 525 bankruptcy. 527 A creditor, such as a bank, which may take the property, including 528 required systems as collatoral for a loan could require that a 529 delegated voucher be obtained. A bank would find a building that 530 needed new systems installed difficult to resale should the bank have 531 to foreclose. It is likely that this requirement would make devices 532 which do not come with delegated vouchers significant liabilities, 533 and that financial institutions (banks, insurance companies) might 534 refuse to lend in this case. 536 As a different example, an owner might initially start with some 537 hosted Registrar (in the cloud perhaps, as a service). Later on, the 538 owner wishes to bring the Registrar in-house (or just change who is 539 providing the Registrar service). Such an activity is effectively a 540 "resale". 542 It is common when a company goes bankrupt that many of it's assets 543 (routers, switches, desktops, as well as furniture) are sold by the 544 court. There are many resellers of digital equipment, and they 545 typically take the devices, factory reset them, verify that they 546 work, and then list them for resale. Such an entity would want to 547 have a delegated voucher for each device. Whether the delegated 548 voucher would be obtained from the original (bankrupt) company, by 549 the court, or directly from the manufacturer is probably a legal 550 problem. 552 Further, the pledges may be resaled many times, and when onboarding, 553 they will receive all vouchers in order with the sale chain, firstly 554 masa vouchour, then 1st intermidate, 2nd intermidate, till to the 555 final dealer. In this case, the pledge's authorization form a signed 556 voucher chain. 558 The following illustrates a delegation voucher for a pledge: { "ietf- 559 voucher-delegated:voucher": { "created-on": "2020-07-14T06:28:31Z", 560 "expire-on": "2022-07-31T01:61:80Z", "assertion": "logged", "serial- 561 number": "JADA123456789", "delegation-enable-flag": true, "pinned- 562 delegation-cert-authority": "base64encodedvalue", "pinned-delegation- 563 cert-name": "base64encodedvalue", "delegation-voucher": 564 "base64encodedvalue", "intermediate-identities": "intermediateId1", 565 "delegation-enable-flag": 1, } } 567 6.2. Case 2: Assembly 569 In some application, many pledges which come from multiple component 570 assembled by a system integrated. They need to to be assembled 571 together in the first sale. In this time, the owner is assembly 572 controller, so the pledge's voucher need to include these delegation 573 options. 575 In addition, there are also transparent assembly, for example rail 576 wagon scenario. Firstly, the assembly onboards normally to get all 577 pledges' vouchers, then this assembly acts as intermidate registrar, 578 who "sell" these pledges to every rail wagon registrar. 580 7. Constraints on Pinning The Delegated Authority 582 TBD 584 8. Privacy Considerations 586 YYY 588 9. Security Considerations 590 9.1. Delegation Vouchers do not expire 592 A significant feature of the [RFC8366] voucher is that it can be 593 short-lived, and often renewed if needed. This goes along with the 594 arguments that renewal is better than revocation explained better in 595 [RFC8739]. However, in order for a delegated voucher to be useful it 596 has to have a life longer than the pessimistic expected life of the 597 manufacturer (MASA). This argues for the expiry time of a voucher to 598 be rather long (decades), if not actually infinite. 600 [RFC8995] makes arguments for why a Pledge dos not need to have a 601 clock that it can trust, because it can use a nonce to verify 602 freshness of the resulting Voucher. The Delegated Voucher can not 603 use a nonce to verify the chain of delegated vouchers presented, 604 although it can use a nonce for the last (non-delegated) voucher. 606 10. IANA Considerations 608 This document requires the following IANA actions: 610 10.1. The IETF XML Registry 612 This document registers a URI in the "IETF XML Registry" [RFC3688]. 613 IANA is asked to register the following: 615 URI: urn:ietf:params:xml:ns:yang:ietf-voucher-delegated 616 Registrant Contact: The ANIMA WG of the IETF. 617 XML: N/A, the requested URI is an XML namespace. 619 10.2. YANG Module Names Registry 621 This document registers a YANG module in the "YANG Module Names" 622 registry [RFC6020]. IANA is asked to register the following: 624 name: ietf-voucher-delegated 625 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-delegated 626 prefix: NONE 627 reference: THIS DOCUMENT 629 11. Acknowledgements 631 Hello. 633 12. Changelog 635 13. References 637 13.1. Normative References 639 [I-D.ietf-anima-constrained-voucher] 640 Richardson, M., Stok, P. V. D., Kampanakis, P., and E. 641 Dijk, "Constrained Voucher Artifacts for Bootstrapping 642 Protocols", Work in Progress, Internet-Draft, draft-ietf- 643 anima-constrained-voucher-10, 21 February 2021, 644 . 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, 650 . 652 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 653 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 654 May 2017, . 656 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 657 "A Voucher Artifact for Bootstrapping Protocols", 658 RFC 8366, DOI 10.17487/RFC8366, May 2018, 659 . 661 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 662 and K. Watsen, "Bootstrapping Remote Secure Key 663 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 664 May 2021, . 666 13.2. Informative References 668 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 669 DOI 10.17487/RFC3688, January 2004, 670 . 672 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 673 the Network Configuration Protocol (NETCONF)", RFC 6020, 674 DOI 10.17487/RFC6020, October 2010, 675 . 677 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 678 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 679 . 681 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 682 Touch Provisioning (SZTP)", RFC 8572, 683 DOI 10.17487/RFC8572, April 2019, 684 . 686 [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor 687 Perales, A., and T. Fossati, "Support for Short-Term, 688 Automatically Renewed (STAR) Certificates in the Automated 689 Certificate Management Environment (ACME)", RFC 8739, 690 DOI 10.17487/RFC8739, March 2020, 691 . 693 Appendix A. Extra references 695 RFC Editor, please remove this section. This section lists 696 references in the YANG. [RFC8174], [RFC8040]. 698 Authors' Addresses 699 Michael Richardson 700 Sandelman Software Works 702 Email: mcr+ietf@sandelman.ca 704 Wei Pan 705 Huawei Technologies 707 Email: william.panwei@huawei.com