idnits 2.17.1 draft-richardson-anima-voucher-delegation-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-anima-bootstrapping-keyinfra]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 330 has weird spacing: '...ndatory false...' -- The document date (September 18, 2020) is 1313 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 (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-43 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-08 Summary: 1 error (**), 0 flaws (~~), 4 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 J. Yang 5 Expires: March 22, 2021 Huawei Technologies Co., Ltd. 6 September 18, 2020 8 Delegated Authority for Bootstrap Voucher Artifacts 9 draft-richardson-anima-voucher-delegation-02 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 [I-D.ietf-anima-bootstrapping-keyinfra] 19 Manufacturer Authorized Signing 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 March 22, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements for the Delegation . . . . . . . . . . . . . 3 57 1.1.1. Device Onboarding with Disconnected or Offline MASA . 3 58 1.1.2. Resale of Devices . . . . . . . . . . . . . . . . . . 3 59 1.1.3. Crypto-agility for Registrar . . . . . . . . . . . . 3 60 1.1.4. Transparent Assemblers/Value-Added-Resellers . . . . 4 61 1.2. Overview of Proposed Solution . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . 12 73 7. Constraints on Pinning The Delegated Authority . . . . . . . 12 74 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 9.1. YANG Module Security Considerations . . . . . . . . . . . 12 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 13 79 10.2. YANG Module Names Registry . . . . . . . . . . . . . . . 13 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 13.2. Informative References . . . . . . . . . . . . . . . . . 14 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 ([I-D.ietf-anima-bootstrapping-keyinfra], 94 [I-D.ietf-anima-constrained-voucher]), and SZTP ([RFC8572]). 96 There are a number of criticisms of the MASA concept. They include: 98 o the MASA must be reachable to the Registar during the onboarding 99 process. 101 o while the use of a nonceless voucher (see {{RFC8366} section 4) 102 can permit the MASA to be offline, it still requires the public 103 key/certificate of the Registrar to be known at issuing time. The 104 device owner is always strongly dependent on the MASA service. 106 o 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 o 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 o it is not possible for a MASA to pin ownership to a Registrar by 115 Certification Authority plus DN. 117 o 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-delegated-voucher 238 +--rw delegation-enable-flag? boolean 240 grouping voucher-delegated-grouping 241 +-- voucher 242 +-- created-on yang:date-and-time 243 +-- expires-on? yang:date-and-time 244 +-- assertion enumeration 245 +-- serial-number string 246 +-- idevid-issuer? binary 247 +-- pinned-domain-cert? binary 248 +-- domain-cert-revocation-checks? boolean 249 +-- nonce? binary 250 +-- last-renewal-date? yang:date-and-time 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-delegated-voucher@2020-01-06.yang" 263 module ietf-delegated-voucher { 264 yang-version 1.1; 266 namespace 267 "urn:ietf:params:xml:ns:yang:ietf-delegated-voucher"; 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."; 275 reference "RFC 8040: RESTCONF Protocol"; 276 } 278 // maybe should import from constrained-voucher instead! 279 import ietf-voucher { 280 prefix "v"; 281 } 283 organization 284 "IETF ANIMA Working Group"; 286 contact 287 "WG Web: 288 WG List: 289 Author: Michael Richardson 290 "; 292 description 293 "This module extends the RFC8366 voucher format to provide 294 a mechanism by which the authority to issue additional vouchers 295 may be delegated to another entity 297 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 298 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 299 and 'OPTIONAL' in the module text are to be interpreted as 300 described in BCP 14 RFC 2119, and RFC8174."; 302 revision "2020-01-06" { 303 description 304 "Initial version"; 305 reference 306 "RFC XXXX: Voucher Profile for Delegation Vouchers"; 307 } 309 rc:yang-data voucher-delegated-artifact { 310 // YANG data template for a voucher. 311 uses voucher-delegated-grouping; 312 } 314 leaf delegation-enable-flag { 315 type boolean; 316 description 317 "A global enable flag to the pledge that it can be delegated 318 (true) or not (false). With default, this flag is false, 319 which is consistent with the voucher artifact in RFC8366. "; 320 } 322 // Grouping defined for future usage 323 grouping voucher-delegated-grouping { 324 description 325 "Grouping to allow reuse/extensions in future work."; 327 uses v:voucher-artifact-grouping { 329 refine voucher/pinned-domain-cert { 330 mandatory false; 331 } 333 augment "voucher" { 334 description "Base the delegated voucher 335 upon the regular one"; 337 leaf pinned-delegation-cert-authority { 338 type binary; 339 description 340 "An subject-public-key-info for a public key of the 341 certificate authority that is to be trusted to issue 342 a delegation voucher to the Registrar. 343 This is not used by end-vouchers, and only valid 344 when delegation-enable-flag is true."; 345 } 347 leaf pinned-delegation-cert-name { 348 type binary; 349 description 350 "A string for the rfc822Name SubjectAltName contents 351 which will be trusted to issue delegation vouchers. 352 This is not used by end-vouchers, and only valid 353 when delegation-enable-flag is true."; 354 } 356 leaf delegation-voucher { 357 type binary; 358 description 359 "The intermediate voucher that delegates 360 authority to the entity that signs this voucher 361 is to be included here, and only valid 362 when delegation-enable-flag is true."; 363 } 365 leaf intermediate-identities { 366 type binary; 367 description 368 "A set of identities that will be needed to 369 validate the chain of vouchers, and only valid 370 when delegation-enable-flag is true. MAY BE REDUNDANT"; 371 } 373 leaf delegation-countdown { 374 type int16; 375 description 376 "Number of delegations still available, and only valid 377 when delegation-enable-flag is true. If zero 378 or omitted, then this is a terminal voucher and 379 may not be further delegated"; 380 } 381 } 383 } 384 } 385 } 386 388 3.2. Bundling of The Vouchers 390 The [I-D.ietf-anima-bootstrapping-keyinfra] defines a mechanism to 391 return a single voucher to the pledge. 393 This protocol requires a number of additional items to be returned to 394 the pledge for evaluation: the series of Intermediate Vouchers that 395 leads to the DASA, and the public keys (often as certificates) of the 396 Registrars on the Delegation Path that leads to each Authority. 398 3.3. Delegation of Multiple Devices 400 A MASA MAY delegate multiple devices to the same Registrar by putting 401 an array of items in the "serial-number" attributes. (XXX-how to 402 describe this in the YANG, and the detailed mechanism, are TBD) 404 4. Enhanced Pledge Behavior 406 The use of a Delegation Voucher requires changes to how the pledge 407 evaluates the voucher that is returned to by the Registrar. 409 There are no significant changes to the voucher-request that is made. 410 The pledge continues to pin the identity of the Registrar to which it 411 is connected, providing a nonce to establish freshness. 413 A pledge which has previously stored a Delegation Voucher and DASA , 414 SHOULD include it in its voucher request. This will be in the form 415 of a certificate provided by the "previous" owner. This allows the 416 Registrar to discover the previous authority for the pledge. As the 417 pledge has no idea if it connecting to an entity that it previously 418 has connected to, it needs to include this certificate anyway. 420 The pledge receives a voucher from the Registrar. This voucher is 421 called the zero voucher. It will observe that the voucher is not 422 signed with its built-in manufacturer trust anchor and it can not 423 verify it. 425 The pledge will examine the voucher to look for the "delegation- 426 voucher" and the "intermediate-identities" attributes within the 427 voucher. A certificate from the set of intermediate-identities is 428 expected to validate the signature on this zeroth end-entity voucher. 429 (XXX- This attribute can be replaced by the CMS certificate chain) 430 The contained delegation-voucher object is to be interpreted as an 431 (Intermediate) Voucher. This first voucher is called the first 432 voucher, or "voucher[1]". Generically, for voucher[i], the voucher 433 found in the delegation-voucher is called voucher[i+1]. 435 If voucher[i] can be validated by a built-in trust anchor, then the 436 process is done. If not, then voucher[i] is examined in a recursive 437 process until there are no further embedded vouchers. The last 438 voucher[n] is expected to be validated by a built-in manufacturer 439 trust anchor. 441 Once the top (n-th) voucher is found, then the pinned-certificate- 442 authority is added to the working set of trust anchors. The "pinned- 443 certificate-name" attribute is used along with the trust anchor to 444 validate the certificate chain provided with the (n-1)th voucher. 445 This is repeated (unwinding the recursive processing) until the 446 zeroth voucher has been validated. 448 5. Changes to Registrar Behavior 450 The Registrar is the component that authenticates the pledge, makes 451 authorization decisions, and distributes vouchers. If the vouchers 452 is delegated, then the registrar need to co-ordinate MASA and DASA. 454 5.1. Discovering The Most Recent Delegated Authority to Use 456 The pledge continues to use its manufacturer issued IDevID when 457 performing BRSKI-style onboarding. The IDevID contains an extension, 458 the MASA URL (see [I-D.ietf-anima-bootstrapping-keyinfra] section 459 2.3.2). The IDevID certificate is not expected to be updated when 460 the device is resold, nor may it be practical for an intermediate 461 owner to be able to replace the IDevID with their own. (Some devices 462 may support having an intermediate owner replace the IDevID, in which 463 case this section does not apply) 465 The Registrar needs to be informed that it should not contact a MASA 466 using the URL in the IDevID, but rather to contact the previous 467 owner's DASA. 469 This can be accomplished by local override, as described in 470 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.4: 472 Registrars MAY include a mechanism to override 473 the MASA URL on a manufacturer-by-manufacturer basis, and within that 474 override it is appropriate to provide alternate anchors. This will 475 typically used by some vendors to establish explicit (or private) 476 trust anchors for validating their MASA that is part of a sales 477 channel integration. 479 The above override needs to be established on a per-device basis. It 480 requires per-device configuration which is very much non-autonomic. 482 There are two other alternatives: 484 1. The Manufacturer could be aware of any Delegation Vouchers that 485 it has issued for a particular device, and when contacted by the 486 Registrar, it could redirect the Registrar to its DASA. And the 487 DASA may redirect the Registrar to its delegated DASA, this 488 process is recursive to the final DASA. 490 2. The Pledge could provide a signed statement from the manufacturer 491 providing the Registrar with a pointer to the DASA. 493 Option 1 requires that the Registrar still contact the MASA, 494 violating most of the goals from Section 1.1. 496 Option 2 requires a signed artifact, and conveniently, the Delegation 497 Voucher is exactly the item needed. The most difficult problem is 498 that the Pledge needs to (a) store one or more Delegation Vouchers in 499 a non-volatile storage that survives factory reset operations, (b) 500 attach these items to the pledge's voucher-request. 502 The extension to the [I-D.ietf-anima-bootstrapping-keyinfra] voucher- 503 request described below provides for a contained for these Delegation 504 Vouchers. 506 6. Applying The Delegation Voucher to Requirements 508 6.1. Case 1: Resale 510 This case has many scenarioes in application. 512 For example, due to the willing of some devices' owner, or due to the 513 creditor or bankruptcy, their devices need to resale to some third 514 party, but they have previously been onboarded without specific 515 authorization from the manufacturer. Aother example is for some 516 owner, which PKI system is on the cloud initially, but later, they 517 wish to change its CA, and it is effectively a "resale". Then, the 518 registrar of third party must override MASA URL, contacting this 519 owner's registrar for voucher. Here, the owner's registrar is 520 delegation authority. 522 Furthurly, the pledges may be resaled many times, and when 523 onboarding, they will receive all vouchers in order with the sale 524 chain, firstly masa vouchour, then 1st intermidate, 2nd intermidate, 525 till to the final dealer. In this case, the pledge's authorization 526 form a signed voucher chain. 528 In addition, for a pledge, resale can't be forever, so the delegation 529 voucher need specify the limit number of resales with "delegation- 530 countdown". 532 The following illustrates a delegation voucher for a pledge: { "ietf- 533 delegated-voucher:voucher": { "created-on": "2020-07-14T06:28:31Z", 534 "expire-on": "2022-07-31T01:61:80Z", "assertion": "logged", "serial- 535 number": "JADA123456789", "delegation-enable-flag": true, "pinned- 536 delegation-cert-authority": "base64encodedvalue", "pinned-delegation- 537 cert-name": "base64encodedvalue", "delegation-voucher": 538 "base64encodedvalue", "intermediate-identities": "intermediateId1", 539 "delegation-countdown": 1, } } 541 6.2. Case 2: Assembly 543 In some application, many pledges which come from multiple componet 544 manufactures, need to be assemblied together in the first sale, In 545 this time, the owner is assembly controller, so the pledge's voucher 546 need to include these delegation options. 548 In addition, there are also transparent assembly, for exmale rail 549 wagon scenario. Firstly, the assembly onboards normally to get all 550 pledges' vouchers, then this assembly acts as intermidate registrar, 551 who "sell" these pledges to every rail wagon registrar. 553 7. Constraints on Pinning The Delegated Authority 555 TBD 557 8. Privacy Considerations 559 YYY 561 9. Security Considerations 563 9.1. YANG Module Security Considerations 565 As described in the Security Considerations section of [RFC8366] 566 (section 7.4), the YANG module specified in this document defines the 567 schema for data that is subsequently encapsulated by a CMS signed- 568 data content type, as described in Section 5 of [RFC5652]. As such, 569 all of the YANG modeled data is protected from modification. 571 The use of YANG to define data structures, via the 'yang-data' 572 statement, is relatively new and distinct from the traditional use of 573 YANG to define an API accessed by network management protocols such 574 as NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason, these 575 guidelines do not follow template described by Section 3.7 of 576 [RFC8407]. 578 10. IANA Considerations 580 This document requires the following IANA actions: 582 10.1. The IETF XML Registry 584 This document registers a URI in the "IETF XML Registry" [RFC3688]. 585 IANA is asked to register the following: 587 URI: urn:ietf:params:xml:ns:yang:ietf-delegated-voucher 588 Registrant Contact: The ANIMA WG of the IETF. 589 XML: N/A, the requested URI is an XML namespace. 591 10.2. YANG Module Names Registry 593 This document registers a YANG module in the "YANG Module Names" 594 registry [RFC6020]. IANA is asked to register the following: 596 name: ietf-delegated-voucher 597 namespace: urn:ietf:params:xml:ns:yang:ietf-delegated-voucher 598 prefix: NONE 599 reference: THIS DOCUMENT 601 11. Acknowledgements 603 Hello. 605 12. Changelog 607 13. References 609 13.1. Normative References 611 [I-D.ietf-anima-bootstrapping-keyinfra] 612 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 613 and K. Watsen, "Bootstrapping Remote Secure Key 614 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 615 keyinfra-43 (work in progress), August 2020. 617 [I-D.ietf-anima-constrained-voucher] 618 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 619 Voucher Artifacts for Bootstrapping Protocols", draft- 620 ietf-anima-constrained-voucher-08 (work in progress), July 621 2020. 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, 625 DOI 10.17487/RFC2119, March 1997, 626 . 628 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 629 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 630 May 2017, . 632 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 633 "A Voucher Artifact for Bootstrapping Protocols", 634 RFC 8366, DOI 10.17487/RFC8366, May 2018, 635 . 637 13.2. Informative References 639 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 640 DOI 10.17487/RFC3688, January 2004, 641 . 643 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 644 RFC 5652, DOI 10.17487/RFC5652, September 2009, 645 . 647 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 648 the Network Configuration Protocol (NETCONF)", RFC 6020, 649 DOI 10.17487/RFC6020, October 2010, 650 . 652 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 653 and A. Bierman, Ed., "Network Configuration Protocol 654 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 655 . 657 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 658 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 659 . 661 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 662 Documents Containing YANG Data Models", BCP 216, RFC 8407, 663 DOI 10.17487/RFC8407, October 2018, 664 . 666 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 667 Touch Provisioning (SZTP)", RFC 8572, 668 DOI 10.17487/RFC8572, April 2019, 669 . 671 Appendix A. Extra references 673 RFC Editor, please remove this section. This section lists 674 references in the YANG. [RFC8174], [RFC8040]. 676 Authors' Addresses 678 Michael Richardson 679 Sandelman Software Works 681 Email: mcr+ietf@sandelman.ca 683 Jie Yang 684 Huawei Technologies Co., Ltd. 686 Email: jay.yang@huawei.com