idnits 2.17.1 draft-ietf-netconf-trust-anchors-12.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 372 has weird spacing: '...on-date yan...' == Line 379 has weird spacing: '...-format ide...' == Line 718 has weird spacing: '...on-date yan...' == Line 728 has weird spacing: '...-format ide...' -- The document date (10 July 2020) is 1384 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 (-34) exists of draft-ietf-netconf-crypto-types-15 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-03 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-17 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-19 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-19 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-19 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-06 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-19 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-10 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Intended status: Standards Track 10 July 2020 5 Expires: 11 January 2021 7 A YANG Data Model for a Truststore 8 draft-ietf-netconf-trust-anchors-12 10 Abstract 12 This document defines a YANG 1.1 data model for configuring globally- 13 accessible bags of certificates and public keys that can be 14 referenced by other data models for trust. 16 Editorial Note (To be removed by RFC Editor) 18 This draft contains placeholder values that need to be replaced with 19 finalized values at the time of publication. This note summarizes 20 all of the substitutions that are needed. No other RFC Editor 21 instructions are specified elsewhere in this document. 23 Artwork in this document contains shorthand references to drafts in 24 progress. Please apply the following replacements: 26 * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- 27 types 29 * "BBBB" --> the assigned RFC value for this draft 31 Artwork in this document contains placeholder values for the date of 32 publication of this draft. Please apply the following replacement: 34 * "2020-07-10" --> the publication date of this draft 36 The following Appendix section is to be removed prior to publication: 38 * Appendix A. Change Log 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 11 January 2021. 57 Copyright Notice 59 Copyright (c) 2020 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Simplified BSD License text 68 as described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3 75 1.2. Specification Language . . . . . . . . . . . . . . . . . 5 76 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 77 2. The "ietf-truststore" Module . . . . . . . . . . . . . . . . 5 78 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 79 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 9 80 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 81 3. Support for Built-in Trust Anchors . . . . . . . . . . . . . 25 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 28 83 4.1. Data at Rest . . . . . . . . . . . . . . . . . . . . . . 28 84 4.2. The "ietf-truststore" YANG Module . . . . . . . . . . . . 29 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 86 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 29 87 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 29 88 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 89 6.1. Normative References . . . . . . . . . . . . . . . . . . 30 90 6.2. Informative References . . . . . . . . . . . . . . . . . 30 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 92 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 32 93 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 32 94 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 32 95 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 33 96 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 33 97 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 33 98 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 33 99 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 33 100 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 34 101 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 34 102 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 34 103 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 34 104 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 35 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 107 1. Introduction 109 This document defines a YANG 1.1 [RFC7950] data model for configuring 110 globally-accessible bags of certificates and public keys that can be 111 referenced by other data models for trust. 113 1.1. Relation to other RFCs 115 This document presents one or more YANG modules [RFC7950] that are 116 part of a collection of RFCs that work together to define 117 configuration modules for clients and servers of both the NETCONF 118 [RFC6241] and RESTCONF [RFC8040] protocols. 120 The modules have been defined in a modular fashion to enable their 121 use by other efforts, some of which are known to be in progress at 122 the time of this writing, with many more expected to be defined in 123 time. 125 The relationship between the various RFCs in the collection is 126 presented in the below diagram. The labels in the diagram represent 127 the primary purpose provided by each RFC. Links the each RFC are 128 provided below the diagram. 130 crypto-types 131 ^ ^ 132 / \ 133 / \ 134 truststore keystore 135 ^ ^ ^ ^ 136 | +---------+ | | 137 | | | | 138 | +------------+ | 139 tcp-client-server | / | | 140 ^ ^ ssh-client-server | | 141 | | ^ tls-client-server 142 | | | ^ ^ http-client-server 143 | | | | | ^ 144 | | | +-----+ +---------+ | 145 | | | | | | 146 | +-----------|--------|--------------+ | | 147 | | | | | | 148 +-----------+ | | | | | 149 | | | | | | 150 | | | | | | 151 netconf-client-server restconf-client-server 153 +=======================+===========================================+ 154 | Label in Diagram | Originating RFC | 155 +=======================+===========================================+ 156 | crypto-types | [I-D.ietf-netconf-crypto-types] | 157 +-----------------------+-------------------------------------------+ 158 | truststore | [I-D.ietf-netconf-trust-anchors] | 159 +-----------------------+-------------------------------------------+ 160 | keystore | [I-D.ietf-netconf-keystore] | 161 +-----------------------+-------------------------------------------+ 162 | tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 163 +-----------------------+-------------------------------------------+ 164 | ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 165 +-----------------------+-------------------------------------------+ 166 | tls-client-server | [I-D.ietf-netconf-tls-client-server] | 167 +-----------------------+-------------------------------------------+ 168 | http-client-server | [I-D.ietf-netconf-http-client-server] | 169 +-----------------------+-------------------------------------------+ 170 | netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 171 +-----------------------+-------------------------------------------+ 172 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 173 +-----------------------+-------------------------------------------+ 175 Table 1: Label to RFC Mapping 177 1.2. Specification Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in BCP 182 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 1.3. Adherence to the NMDA 187 This document in compliant with the Network Management Datastore 188 Architecture (NMDA) [RFC8342]. For instance, trust anchors installed 189 during manufacturing (e.g., for trusted well-known services), are 190 expected to appear in (see Section 3). 192 2. The "ietf-truststore" Module 194 This section defines a YANG 1.1 [RFC7950] module that defines a 195 "truststore" and groupings supporting downstream modules to reference 196 the truststore or have locally-defined definitions. 198 2.1. Data Model Overview 200 2.1.1. Features 202 The following diagram lists all the "feature" statements defined in 203 the "ietf-truststore" module: 205 Features: 206 +-- truststore-supported 207 +-- local-definitions-supported 208 +-- certificates 209 +-- public-keys 211 2.1.2. Typedefs 213 The following diagram lists the "typedef" statements defined in the 214 "ietf-truststore" module: 216 Typedefs: 217 leafref 218 +-- certificate-bag-ref 219 +-- certificate-ref 220 +-- public-key-bag-ref 221 +-- public-key-ref 223 Comments: 225 * All of the typedefs defined in the "ietf-truststore" module extend 226 the base "leafref" type defined in [RFC7950]. 228 * The leafrefs refer to certificates, public keys, and bags. These 229 typedefs are provided primarily as an aid to downstream modules 230 that import the "ietf-truststore" module. 232 2.1.3. Groupings 234 The following diagram lists all the "grouping" statements defined in 235 the "ietf-truststore" module: 237 Groupings: 238 +-- local-or-truststore-certs-grouping 239 +-- local-or-truststore-public-keys-grouping 240 +-- truststore-grouping 242 Each of these groupings are presented in the following subsections. 244 2.1.3.1. The "local-or-truststore-certs-grouping" Grouping 246 The following tree diagram [RFC8340] illustrates the "local-or- 247 truststore-certs-grouping" grouping: 249 grouping local-or-truststore-certs-grouping 250 +-- (local-or-truststore) 251 +--:(local) {local-definitions-supported}? 252 | +-- local-definition 253 | +-- certificate* [name] 254 | +-- name? string 255 | +---u ct:trust-anchor-cert-grouping 256 +--:(truststore) {truststore-supported,certificates}? 257 +-- truststore-reference? ts:certificate-bag-ref 259 Comments: 261 * The "local-or-truststore-certs-grouping" grouping is provided 262 soley as convenience to downstream modules that wish to offer an 263 option as to if a bag of certificates can be defined locally or as 264 a reference to a bag in the truststore. 266 * A "choice" statement is used to expose the various options. Each 267 option is enabled by a "feature" statement. Additional "case" 268 statements MAY be augmented in if, e.g., there is a need to 269 reference a bag in an alternate location. 271 * For the "local-definition" option, the "certificate" node uses the 272 "trust-anchor-cert-grouping" grouping discussed in Section 2.1.3.6 273 of [I-D.ietf-netconf-crypto-types]. 275 * For the "truststore" option, the "truststore-reference" is an 276 instance of the "certificate-bag-ref" discussed in Section 2.1.2. 278 2.1.3.2. The "local-or-truststore-public-keys-grouping" Grouping 280 The following tree diagram [RFC8340] illustrates the "local-or- 281 truststore-public-keys-grouping" grouping: 283 grouping local-or-truststore-public-keys-grouping 284 +-- (local-or-truststore) 285 +--:(local) {local-definitions-supported}? 286 | +-- local-definition 287 | +-- public-key* [name] 288 | +-- name? string 289 | +---u ct:public-key-grouping 290 +--:(truststore) {truststore-supported,public-keys}? 291 +-- truststore-reference? ts:public-key-bag-ref 293 Comments: 295 * The "local-or-truststore-public-keys-grouping" grouping is 296 provided soley as convenience to downstream modules that wish to 297 offer an option as to if a bag of public keys can be defined 298 locally or as a reference to a bag in the truststore. 300 * A "choice" statement is used to expose the various options. Each 301 option is enabled by a "feature" statement. Additional "case" 302 statements MAY be augmented in if, e.g., there is a need to 303 reference a bag in an alternate location. 305 * For the "local-definition" option, the "public-key" node uses the 306 "public-key-grouping" grouping discussed in Section 2.1.3.3 of 307 [I-D.ietf-netconf-crypto-types]. 309 * For the "truststore" option, the "truststore-reference" is an 310 instance of the "certificate-bag-ref" discussed in Section 2.1.2. 312 2.1.3.3. The "truststore-grouping" Grouping 314 The following tree diagram [RFC8340] illustrates the "truststore- 315 grouping" grouping: 317 grouping truststore-grouping 318 +-- certificate-bags! {certificates}? 319 | +-- certificate-bag* [name] 320 | +-- name? string 321 | +-- description? string 322 | +-- certificate* [name] 323 | +-- name? string 324 | +---u ct:trust-anchor-cert-grouping 325 +-- public-key-bags! {public-keys}? 326 +-- public-key-bag* [name] 327 +-- name? string 328 +-- description? string 329 +-- public-key* [name] 330 +-- name? string 331 +---u ct:public-key-grouping 333 Comments: 335 * The "truststore-grouping" grouping is defines a truststore 336 instance as being composed of certificates and/or public keys, 337 both of which are enabled by "feature" statements. The stucture 338 supporting certificates and public keys is essentially the same, 339 having an outer list of "bags" containing in inner list of objects 340 (certificates or public keys). The bags enable trust anchors 341 serving a common purpose to be grouped referenced together. 343 * For certificates, each certificate is defined by the "trust- 344 anchor-cert-grouping" grouping Section 2.1.3.6 of 345 [I-D.ietf-netconf-crypto-types]. Thus the "cert-data" node is a 346 CMS structure that can be composed of a chain of one or more 347 certificates. Additionally, the "certificate-expiration" 348 notification enables the server to alert clients when certificates 349 are nearing or have already expired. 351 * For public keys, each public key is defined by the "public-key- 352 grouping" grouping Section 2.1.3.3 of 353 [I-D.ietf-netconf-crypto-types]. Thus the "public-key" node can 354 be one of any number of structures specified by the "public-key- 355 format" identity node. 357 2.1.4. Protocol-accessible Nodes 359 The following diagram lists all the protocol-accessible nodes defined 360 in the "ietf-truststore" module: 362 module: ietf-truststore 363 +--rw truststore 364 +--rw certificate-bags! {certificates}? 365 | +--rw certificate-bag* [name] 366 | +--rw name string 367 | +--rw description? string 368 | +--rw certificate* [name] 369 | +--rw name string 370 | +--rw cert-data trust-anchor-cert-cms 371 | +---n certificate-expiration 372 | +-- expiration-date yang:date-and-time 373 +--rw public-key-bags! {public-keys}? 374 +--rw public-key-bag* [name] 375 +--rw name string 376 +--rw description? string 377 +--rw public-key* [name] 378 +--rw name string 379 +--rw public-key-format identityref 380 +--rw public-key binary 382 Comments: 384 * Protocol-accessible nodes are those nodes that are accessible when 385 the module is "implemented", as described in Section 5.6.5 of 386 [RFC7950]. 388 * For the "ietf-truststore" module, the protcol-accessible nodes are 389 an instance of the "truststore-grouping" discussed in 390 Section 2.1.3.3 grouping. 392 * The reason for why "truststore-grouping" exists separate from the 393 protocol-accessible nodes definition is so as to enable instances 394 of the truststore to be instantiated in other locations, as may be 395 needed or desired by some modules. 397 2.2. Example Usage 399 The examples in this section are encoded using XML, such as might be 400 the case when using the NETCONF protocol. Other encodings MAY be 401 used, such as JSON when using the RESTCONF protocol. 403 2.2.1. A Truststore Instance 405 This section presents an example illustrating trust anchors in 406 , as per Section 2.1.4. Please see Section 3 for an 407 example illustrating built-in values in . 409 The example contained in this secton defines eight bags of trust 410 anchors. There are four certificate-based bags and four public key 411 based bags. The following diagram provides an overview of contents 412 in the example: 414 Certificate Bags 415 +-- CA certificates for authenticating a set a remote servers 416 +-- EE certificates for authenticating a set a remote servers 417 +-- CA certificates for authenticating a set a remote clients 418 +-- EE certificates for authenticating a set a remote clients 420 Public Key Bags 421 +-- SSH keys to authenticate a set of remote SSH server 422 +-- SSH keys to authenticate a set of remote SSH clients 423 +-- Raw public keys to authenticate a set of remote SSH server 424 +-- Raw public keys to authenticate a set of remote SSH clients 426 Following is the full example: 428 432 433 435 436 437 trusted-server-ca-certs 438 439 Trust anchors (i.e. CA certs) used to authenticate server 440 certificates. A server certificate is authenticated if its 441 end-entity certificate has a chain of trust to one of these 442 certificates. 443 444 445 Server Cert Issuer #1 446 base64encodedvalue== 447 448 449 Server Cert Issuer #2 450 base64encodedvalue== 451 452 454 455 456 trusted-server-ee-certs 457 458 Specific end-entity certificates used to authenticate server 459 certificates. A server certificate is authenticated if its 460 end-entity certificate is an exact match to one of these 461 certificates. 462 463 464 My Application #1 465 base64encodedvalue== 466 467 468 My Application #2 469 base64encodedvalue== 470 471 473 474 475 trusted-client-ca-certs 476 477 Trust anchors (i.e. CA certs) used to authenticate client 478 certificates. A client certificate is authenticated if its 479 end-entity certificate has a chain of trust to one of these 480 certificates. 481 482 483 Client Identity Issuer #1 484 base64encodedvalue== 485 486 487 Client Identity Issuer #2 488 base64encodedvalue== 489 490 492 493 494 trusted-client-ee-certs 495 496 Specific end-entity certificates used to authenticate client 497 certificates. A client certificate is authenticated if its 498 end-entity certificate is an exact match to one of these 499 certificates. 500 501 502 George Jetson 503 base64encodedvalue== 504 505 506 Fred Flintstone 507 base64encodedvalue== 508 509 510 512 513 515 516 517 trusted-ssh-public-keys 518 519 Specific SSH public keys used to authenticate SSH server 520 public keys. An SSH server public key is authenticated if 521 its public key is an exact match to one of these public keys. 523 This list of SSH public keys is analogous to OpenSSH's 524 "/etc/ssh/ssh_known_hosts" file. 525 526 527 corp-fw1 528 529 ct:ssh-public-key-format 530 531 base64encodedvalue== 532 533 534 corp-fw2 535 536 ct:ssh-public-key-format 537 538 base64encodedvalue== 539 540 542 543 544 SSH Public Keys for Application A 545 546 SSH public keys used to authenticate application A's SSH 547 public keys. An SSH public key is authenticated if it 548 is an exact match to one of these public keys. 549 550 551 Application Instance #1 552 553 ct:ssh-public-key-format 554 555 base64encodedvalue== 556 557 558 Application Instance #2 559 560 ct:ssh-public-key-format 561 562 base64encodedvalue== 563 564 566 567 568 Raw Public Keys for TLS Servers 569 570 Raw Public Key #1 571 572 ct:subject-public-key-info-format 573 base64encodedvalue== 574 575 576 Raw Public Key #2 577 578 ct:subject-public-key-info-format 579 580 base64encodedvalue== 581 582 584 585 586 Raw Public Keys for TLS Clients 587 588 Raw Public Key #1 589 590 ct:subject-public-key-info-format 591 592 base64encodedvalue== 593 594 595 Raw Public Key #2 596 597 ct:subject-public-key-info-format 598 599 base64encodedvalue== 600 602 603 604 606 2.2.2. A Certificate Expiration Notification 608 The following example illustrates the "certificate-expiration" 609 notification (per Section 2.1.3.4 of [I-D.ietf-netconf-crypto-types]) 610 for a certificate configured in the truststore in Section 2.2.1. 612 =============== NOTE: '\' line wrapping per RFC 8792 ================ 614 616 2018-05-25T00:01:00Z 617 618 619 620 trusted-client-ee-certs 621 622 George Jetson 623 624 2018-08-05T14:18:53-05:00 626 627 628 629 630 631 633 2.2.3. The "Local or Truststore" Groupings 635 This section illustrates the various "local-or-truststore" groupings 636 defined in the "ietf-truststore" module, specifically the "local-or- 637 truststore-certs-grouping" (Section 2.1.3.1) and "local-or- 638 truststore-public-keys-grouping" (Section 2.1.3.2), groupings. 640 The following non-normative module is defined to illustrate these 641 groupings: 643 module ex-truststore-usage { 644 yang-version 1.1; 646 namespace "http://example.com/ns/example-truststore-usage"; 647 prefix "etu"; 649 import ietf-truststore { 650 prefix ts; 651 reference 652 "RFC BBBB: A YANG Data Model for a Truststore"; 653 } 655 organization 656 "Example Corporation"; 658 contact 659 "Author: YANG Designer "; 661 description 662 "This module illustrates notable groupings defined in 663 the 'ietf-truststore' module."; 665 revision "2020-07-10" { 666 description 667 "Initial version"; 668 reference 669 "RFC BBBB: A YANG Data Model for a Truststore"; 670 } 672 container truststore-usage { 673 description 674 "An illustration of the various truststore groupings."; 676 list cert { 677 key name; 678 leaf name { 679 type string; 680 description 681 "An arbitrary name for this cert."; 682 } 683 uses ts:local-or-truststore-certs-grouping; 684 description 685 "An cert that may be configured locally or be 686 a reference to a cert in the truststore."; 687 } 689 list public-key { 690 key name; 691 leaf name { 692 type string; 693 description 694 "An arbitrary name for this cert."; 695 } 696 uses ts:local-or-truststore-public-keys-grouping; 697 description 698 "An public key that may be configured locally or be 699 a reference to a public key in the truststore."; 700 } 701 } 702 } 704 The tree diagram [RFC8340] for this example module follows: 706 module: ex-truststore-usage 707 +--rw truststore-usage 708 +--rw cert* [name] 709 | +--rw name string 710 | +--rw (local-or-truststore) 711 | +--:(local) {local-definitions-supported}? 712 | | +--rw local-definition 713 | | +--rw certificate* [name] 714 | | +--rw name string 715 | | +--rw cert-data 716 | | | trust-anchor-cert-cms 717 | | +---n certificate-expiration 718 | | +-- expiration-date yang:date-and-time 719 | +--:(truststore) {truststore-supported,certificates}? 720 | +--rw truststore-reference? ts:certificate-bag-ref 721 +--rw public-key* [name] 722 +--rw name string 723 +--rw (local-or-truststore) 724 +--:(local) {local-definitions-supported}? 725 | +--rw local-definition 726 | +--rw public-key* [name] 727 | +--rw name string 728 | +--rw public-key-format identityref 729 | +--rw public-key binary 730 +--:(truststore) {truststore-supported,public-keys}? 731 +--rw truststore-reference? ts:public-key-bag-ref 733 The following example provides two equivalent instances of each 734 grouping, the first being a reference to a truststore and the second 735 being locally-defined. The instance having a reference to a 736 truststore is consistent with the truststore defined in 737 Section 2.2.1. The two instances are equivalent, as the locally- 738 defined instance example contains the same values defined by the 739 truststore instance referenced by its sibling example. 741 =============== NOTE: '\' line wrapping per RFC 8792 ================ 743 747 748 750 751 example 1a 752 trusted-client-ca-certs 754 756 757 example 1b 758 759 my-trusted-client-ca-certs 760 761 Client Identity Issuer #1 762 base64encodedvalue== 763 764 765 Client Identity Issuer #2 766 base64encodedvalue== 767 768 769 771 772 774 775 example 2a 776 trusted-ssh-public-keys 778 780 781 example 2b 782 783 trusted-ssh-public-keys 784 785 corp-fw1 786 787 ct:ssh-public-key-format 789 790 base64encodedvalue== 791 792 793 corp-fw2 794 795 ct:ssh-public-key-format 796 797 base64encodedvalue== 798 799 800 802 804 2.3. YANG Module 806 This YANG module imports modules from [RFC8341] and 807 [I-D.ietf-netconf-crypto-types]. 809 file "ietf-truststore@2020-07-10.yang" 811 module ietf-truststore { 812 yang-version 1.1; 813 namespace "urn:ietf:params:xml:ns:yang:ietf-truststore"; 814 prefix ts; 816 import ietf-netconf-acm { 817 prefix nacm; 818 reference 819 "RFC 8341: Network Configuration Access Control Model"; 820 } 822 import ietf-crypto-types { 823 prefix ct; 824 reference 825 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 826 } 828 organization 829 "IETF NETCONF (Network Configuration) Working Group"; 831 contact 832 "WG Web : 833 WG List : 834 Author : Kent Watsen "; 836 description 837 "This module defines a Truststore to centralize management 838 of trust anchors including certificates and public keys. 840 Copyright (c) 2020 IETF Trust and the persons identified 841 as authors of the code. All rights reserved. 843 Redistribution and use in source and binary forms, with 844 or without modification, is permitted pursuant to, and 845 subject to the license terms contained in, the Simplified 846 BSD License set forth in Section 4.c of the IETF Trust's 847 Legal Provisions Relating to IETF Documents 848 (https://trustee.ietf.org/license-info). 850 This version of this YANG module is part of RFC BBBB 851 (https://www.rfc-editor.org/info/rfcBBBB); see the RFC 852 itself for full legal notices. 854 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 855 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 856 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 857 are to be interpreted as described in BCP 14 (RFC 2119) 858 (RFC 8174) when, and only when, they appear in all 859 capitals, as shown here."; 861 revision 2020-07-10 { 862 description 863 "Initial version"; 864 reference 865 "RFC BBBB: A YANG Data Model for a Truststore"; 866 } 868 /****************/ 869 /* Features */ 870 /****************/ 872 feature truststore-supported { 873 description 874 "The 'truststore-supported' feature indicates that the 875 server supports the Truststore (i.e., implements the 876 'ietf-truststore' module)."; 877 } 879 feature local-definitions-supported { 880 description 881 "The 'local-definitions-supported' feature indicates that 882 the server supports locally-defined trust anchors."; 883 } 884 feature certificates { 885 description 886 "The 'certificates' feature indicates that the server 887 implements the /truststore/certificate-bags subtree."; 888 } 890 feature public-keys { 891 description 892 "The 'public-keys' feature indicates that the server 893 implements the /truststore/public-key-bags subtree."; 894 } 896 /****************/ 897 /* Typedefs */ 898 /****************/ 900 typedef certificate-bag-ref { 901 type leafref { 902 path "/ts:truststore/ts:certificate-bags/" 903 + "ts:certificate-bag/ts:name"; 904 } 905 description 906 "This typedef defines a reference to a certificate bag 907 defined in the Truststore."; 908 } 910 typedef certificate-ref { 911 type leafref { 912 path "/ts:truststore/certificate-bags/certificate-bag" + 913 "[name = current()/../certificate-bag]/certificate/name"; 914 } 915 description 916 "This typedef define a reference to a specific certificate 917 in a certificate bag defined in the Truststore. This 918 typedef requires that there exist a sibling 'leaf' node 919 called 'certificate-bag' that SHOULD have the typedef 920 'certificate-bag-ref'."; 921 } 923 typedef public-key-bag-ref { 924 type leafref { 925 path "/ts:truststore/ts:public-key-bags/" 926 + "ts:public-key-bag/ts:name"; 927 } 928 description 929 "This typedef define a reference to a public key bag 930 defined in the Truststore."; 931 } 932 typedef public-key-ref { 933 type leafref { 934 path "/ts:truststore/public-key-bags/public-key-bag" + 935 "[name = current()/../public-key-bag]/" + 936 "public-key/name"; 937 } 938 description 939 "This typedef define a reference to a specific public key 940 in a public key bag defined in the Truststore. This 941 typedef requires that there exist a sibling 'leaf' node 942 called 'public-key-bag' that SHOULD have the typedef 943 'public-key-bag-ref'."; 944 } 946 /*****************/ 947 /* Groupings */ 948 /*****************/ 950 grouping local-or-truststore-certs-grouping { 951 description 952 "A grouping that allows the certificates to be either 953 configured locally, within the using data model, or be a 954 reference to a certificate bag stored in the Truststore."; 955 choice local-or-truststore { 956 nacm:default-deny-write; 957 mandatory true; 958 case local { 959 if-feature "local-definitions-supported"; 960 container local-definition { 961 description 962 "A container for locally configured trust anchor 963 certificates."; 964 list certificate { 965 key "name"; 966 min-elements 1; 967 description 968 "A trust anchor certificate."; 969 leaf name { 970 type string; 971 description 972 "An arbitrary name for this certificate."; 973 } 974 uses ct:trust-anchor-cert-grouping { 975 refine "cert-data" { 976 mandatory true; 977 } 978 } 980 } 981 } 982 } 983 case truststore { 984 if-feature "truststore-supported"; 985 if-feature "certificates"; 986 leaf truststore-reference { 987 type ts:certificate-bag-ref; 988 description 989 "A reference to a certificate bag that exists in the 990 Truststore."; 991 } 992 } 993 description 994 "A choice between an inlined definition and a definition 995 that exists in the Truststore."; 996 } 997 } 999 grouping local-or-truststore-public-keys-grouping { 1000 description 1001 "A grouping that allows the public keys to be either 1002 configured locally, within the using data model, or be a 1003 reference to a public key bag stored in the Truststore."; 1004 choice local-or-truststore { 1005 nacm:default-deny-write; 1006 mandatory true; 1007 case local { 1008 if-feature "local-definitions-supported"; 1009 container local-definition { 1010 description 1011 "Container to hold local public key definitions."; 1012 list public-key { 1013 key name; 1014 description 1015 "A public key definition."; 1016 leaf name { 1017 type string; 1018 description 1019 "An arbitrary name for this public key."; 1020 } 1021 uses ct:public-key-grouping; 1022 } 1023 } 1024 } 1025 case truststore { 1026 if-feature "truststore-supported"; 1027 if-feature "public-keys"; 1028 leaf truststore-reference { 1029 type ts:public-key-bag-ref; 1030 description 1031 "A reference to a bag of public keys that exist 1032 in the Truststore."; 1033 } 1034 } 1035 description 1036 "A choice between an inlined definition and a definition 1037 that exists in the Truststore."; 1038 } 1039 } 1041 grouping truststore-grouping { 1042 description 1043 "Grouping definition enables use in other contexts. Where 1044 used, implementations SHOULD augment new 'case' statements 1045 into the local-or-truststore 'choice' statements to supply 1046 leafrefs to the model-specific location."; 1047 container certificate-bags { 1048 nacm:default-deny-write; 1049 if-feature "certificates"; 1050 presence 1051 "Indicates that certificate bags have been configured."; 1052 description 1053 "A collection of certificate bags."; 1054 list certificate-bag { 1055 key "name"; 1056 min-elements 1; 1057 description 1058 "A bag of certificates. Each bag of certificates SHOULD 1059 be for a specific purpose. For instance, one bag could 1060 be used to authenticate a specific set of servers, while 1061 another could be used to authenticate a specific set of 1062 clients."; 1063 leaf name { 1064 type string; 1065 description 1066 "An arbitrary name for this bag of certificates."; 1067 } 1068 leaf description { 1069 type string; 1070 description 1071 "A description for this bag of certificates. The 1072 intended purpose for the bag SHOULD be described."; 1073 } 1074 list certificate { 1075 key "name"; 1076 min-elements 1; 1077 description 1078 "A trust anchor certificate."; 1079 leaf name { 1080 type string; 1081 description 1082 "An arbitrary name for this certificate."; 1083 } 1084 uses ct:trust-anchor-cert-grouping { 1085 refine "cert-data" { 1086 mandatory true; 1087 } 1088 } 1089 } 1090 } 1091 } 1092 container public-key-bags { 1093 nacm:default-deny-write; 1094 if-feature "public-keys"; 1095 presence 1096 "Indicates that public keys have been configured."; 1097 description 1098 "A collection of public key bags."; 1099 list public-key-bag { 1100 key "name"; 1101 min-elements 1; 1102 description 1103 "A bag of public keys. Each bag of keys SHOULD be for 1104 a specific purpose. For instance, one bag could be used 1105 authenticate a specific set of servers, while another 1106 could be used to authenticate a specific set of clients."; 1107 leaf name { 1108 type string; 1109 description 1110 "An arbitrary name for this bag of public keys."; 1111 } 1112 leaf description { 1113 type string; 1114 description 1115 "A description for this bag public keys. The 1116 intended purpose for the bag SHOULD be described."; 1117 } 1118 list public-key { 1119 key "name"; 1120 min-elements 1; 1121 description 1122 "A public key."; 1124 leaf name { 1125 type string; 1126 description 1127 "An arbitrary name for this public key."; 1128 } 1129 uses ct:public-key-grouping; 1130 } 1131 } 1132 } 1133 } 1135 /*********************************/ 1136 /* Protocol accessible nodes */ 1137 /*********************************/ 1139 container truststore { 1140 nacm:default-deny-write; 1141 description 1142 "The Truststore contains bags of certificates and 1143 public keys."; 1144 uses truststore-grouping; 1145 } 1146 } 1148 1150 3. Support for Built-in Trust Anchors 1152 In some implementations, a server may define some built-in trust 1153 anchors. For instance, there may be built-in trust anchors enabling 1154 the server to securely connect to well-known services (e.g., an SZTP 1155 [RFC8572] bootstrap server) or public CA certificates to connect to 1156 arbitrary services using public PKI. 1158 Built-in trust anchors are expected to be set by a vendor-specific 1159 process. Any ability for operators to modify built-in trust anchors 1160 is outside the scope of this document. 1162 As built-in trust anchors are provided by the system, they are 1163 present in . The example below illustrates what the 1164 Truststore in might look like for a server in its 1165 factory default state. 1167 1172 1174 1175 Built-In Manufacturer CA Certificates 1176 1177 Certificates built into the device for authenticating 1178 manufacturer-signed objects, such as TLS server certificates, 1179 vouchers, etc. 1180 1181 1182 Manufacturer Root CA Cert 1183 base64encodedvalue== 1184 1185 1187 1188 Built-In Public CA Certificates 1189 1190 Certificates built into the device for authenticating 1191 certificates issued by public certificate authorities, 1192 such as the end-entity certificate for web servers. 1193 1194 1195 Public Root CA Cert 1 1196 base64encodedvalue== 1197 1198 1199 Public Root CA Cert 2 1200 base64encodedvalue== 1201 1202 1203 Public Root CA Cert 3 1204 base64encodedvalue== 1205 1206 1208 1209 1210 In order for the built-in trust anchors to be referenced by 1211 configuration, the referenced certificates MUST first be copied into 1212 . The certificates SHOULD be copied into using 1213 the same "key" values, so that the server can bind them to the built- 1214 in entries. 1216 Built-in certificates MAY be copied into other parts of the 1217 configuration but, by doing so, they lose their association to the 1218 built-in entries and any assurances afforded by knowing they are the 1219 built-in certificates. 1221 Only the referenced certificates need to be copied; that is, the 1222 certificates in MAY be a subset of the built-in 1223 certificates define in . No certificates may be added 1224 or changed; that is, the certificates in MUST be a subset 1225 (which includes the whole of the set) of the built-in certificates 1226 define in . 1228 A server MUST reject attempts to modify any aspect of built-in trust 1229 anchors, both the certificates themselves and the bags that contain 1230 them. That these certificates are "configured" in is an 1231 illusion, as they are strictly a read-only subset of that which must 1232 already exist in . 1234 The following example illustrates how a single built-in public CA 1235 certificate from the previous example has been propagated to 1236 : 1238 1241 1243 1244 Built-In Public CA Certificates 1245 1246 Certificates built into the device for authenticating 1247 certificates issued by public certificate authorities, 1248 such as the end-entity certificate for web servers. 1250 Only the subset of the certificates that are referenced 1251 by other configuration nodes need to be copied. For 1252 instance, only "Public Root CA Cert 3" is present here. 1254 No new certificates can be added, nor existing certificate 1255 values changed. Missing certificates have no effect on 1256 "operational" when the configuration is applied. 1257 1258 1259 Public Root CA Cert 3 1260 base64encodedvalue== 1261 1262 1264 1265 1267 4. Security Considerations 1269 4.1. Data at Rest 1271 The YANG module defined in this document defines a mechanism called a 1272 "truststore" that, by its name, suggests that it will protect its 1273 contents from unauthorized modification. 1275 Security controls for the API (i.e., data in motion) are discussed in 1276 Section 4.2, but controls for the data at rest cannot be specified by 1277 the YANG module. 1279 In order to satisfy the expectations of a "truststore", it is 1280 RECOMMENDED that implementations ensure that the truststore contents 1281 are signed when persisted to non-volatile memory, to prevent 1282 unauthorized modifications from being made undetected. 1284 4.2. The "ietf-truststore" YANG Module 1286 The YANG module defined in this document is designed to be accessed 1287 via YANG based management protocols, such as NETCONF [RFC6241] and 1288 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1289 implement secure transport layers (e.g., SSH, TLS) with mutual 1290 authentication. 1292 The NETCONF access control model (NACM) [RFC8341] provides the means 1293 to restrict access for particular users to a pre-configured subset of 1294 all available protocol operations and content. 1296 None of the readable data nodes defined in this YANG module are 1297 considered sensitive or vulnerable in network environments. The NACM 1298 "default-deny-all" extension has not been set for any data nodes 1299 defined in this module. 1301 All of the writable data nodes defined by this module, both in the 1302 "grouping" statements as well as the protocol-accessible "truststore" 1303 instance, may be considered sensitive or vulnerable in some network 1304 environments. For instance, any modification to a trust anchor or 1305 reference to a trust anchor may dramatically alter the implemented 1306 security policy. For this reason, the NACM extension "default-deny- 1307 write" has been set for all data nodes defined in this module. 1309 This module does not define any RPCs, actions, or notifications, and 1310 thus the security consideration for such is not provided here. 1312 5. IANA Considerations 1314 5.1. The "IETF XML" Registry 1316 This document registers one URI in the "ns" subregistry of the IETF 1317 XML Registry [RFC3688]. Following the format in [RFC3688], the 1318 following registration is requested: 1320 URI: urn:ietf:params:xml:ns:yang:ietf-truststore 1321 Registrant Contact: The NETCONF WG of the IETF. 1322 XML: N/A, the requested URI is an XML namespace. 1324 5.2. The "YANG Module Names" Registry 1326 This document registers one YANG module in the YANG Module Names 1327 registry [RFC6020]. Following the format in [RFC6020], the the 1328 following registration is requested: 1330 name: ietf-truststore 1331 namespace: urn:ietf:params:xml:ns:yang:ietf-truststore 1332 prefix: ts 1333 reference: RFC BBBB 1335 6. References 1337 6.1. Normative References 1339 [I-D.ietf-netconf-crypto-types] 1340 Watsen, K., "Common YANG Data Types for Cryptography", 1341 Work in Progress, Internet-Draft, draft-ietf-netconf- 1342 crypto-types-15, 20 May 2020, 1343 . 1346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1347 Requirement Levels", BCP 14, RFC 2119, 1348 DOI 10.17487/RFC2119, March 1997, 1349 . 1351 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1352 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1353 . 1355 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1356 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1357 May 2017, . 1359 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1360 Access Control Model", STD 91, RFC 8341, 1361 DOI 10.17487/RFC8341, March 2018, 1362 . 1364 6.2. Informative References 1366 [I-D.ietf-netconf-http-client-server] 1367 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 1368 Servers", Work in Progress, Internet-Draft, draft-ietf- 1369 netconf-http-client-server-03, 20 May 2020, 1370 . 1373 [I-D.ietf-netconf-keystore] 1374 Watsen, K., "A YANG Data Model for a Keystore", Work in 1375 Progress, Internet-Draft, draft-ietf-netconf-keystore-17, 1376 20 May 2020, . 1379 [I-D.ietf-netconf-netconf-client-server] 1380 Watsen, K., "NETCONF Client and Server Models", Work in 1381 Progress, Internet-Draft, draft-ietf-netconf-netconf- 1382 client-server-19, 20 May 2020, 1383 . 1386 [I-D.ietf-netconf-restconf-client-server] 1387 Watsen, K., "RESTCONF Client and Server Models", Work in 1388 Progress, Internet-Draft, draft-ietf-netconf-restconf- 1389 client-server-19, 20 May 2020, 1390 . 1393 [I-D.ietf-netconf-ssh-client-server] 1394 Watsen, K. and G. Wu, "YANG Groupings for SSH Clients and 1395 SSH Servers", Work in Progress, Internet-Draft, draft- 1396 ietf-netconf-ssh-client-server-19, 20 May 2020, 1397 . 1400 [I-D.ietf-netconf-tcp-client-server] 1401 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 1402 and TCP Servers", Work in Progress, Internet-Draft, draft- 1403 ietf-netconf-tcp-client-server-06, 16 June 2020, 1404 . 1407 [I-D.ietf-netconf-tls-client-server] 1408 Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and 1409 TLS Servers", Work in Progress, Internet-Draft, draft- 1410 ietf-netconf-tls-client-server-19, 20 May 2020, 1411 . 1414 [I-D.ietf-netconf-trust-anchors] 1415 Watsen, K., "A YANG Data Model for a Truststore", Work in 1416 Progress, Internet-Draft, draft-ietf-netconf-trust- 1417 anchors-10, 20 May 2020, . 1420 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1421 DOI 10.17487/RFC3688, January 2004, 1422 . 1424 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1425 the Network Configuration Protocol (NETCONF)", RFC 6020, 1426 DOI 10.17487/RFC6020, October 2010, 1427 . 1429 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1430 and A. Bierman, Ed., "Network Configuration Protocol 1431 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1432 . 1434 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1435 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1436 . 1438 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1439 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1440 . 1442 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1443 and R. Wilton, "Network Management Datastore Architecture 1444 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1445 . 1447 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1448 Touch Provisioning (SZTP)", RFC 8572, 1449 DOI 10.17487/RFC8572, April 2019, 1450 . 1452 Appendix A. Change Log 1454 This section is to be removed before publishing as an RFC. 1456 A.1. 00 to 01 1458 * Added features "x509-certificates" and "ssh-host-keys". 1460 * Added nacm:default-deny-write to "trust-anchors" container. 1462 A.2. 01 to 02 1464 * Switched "list pinned-certificate" to use the "trust-anchor-cert- 1465 grouping" from crypto-types. Effectively the same definition as 1466 before. 1468 A.3. 02 to 03 1470 * Updated copyright date, boilerplate template, affiliation, folding 1471 algorithm, and reformatted the YANG module. 1473 A.4. 03 to 04 1475 * Added groupings 'local-or-truststore-certs-grouping' and 'local- 1476 or-truststore-host-keys-grouping', matching similar definitions in 1477 the keystore draft. Note new (and incomplete) "truststore" usage! 1479 * Related to above, also added features 'truststore-supported' and 1480 'local-trust-anchors-supported'. 1482 A.5. 04 to 05 1484 * Renamed "trust-anchors" to "truststore" 1486 * Removed "pinned." prefix everywhere, to match truststore rename 1488 * Moved everything under a top-level 'grouping' to enable use in 1489 other contexts. 1491 * Renamed feature from 'local-trust-anchors-supported' to 'local- 1492 definitions-supported' (same name used in keystore) 1494 * Removed the "require-instance false" statement from the "*-ref" 1495 typedefs. 1497 * Added missing "ssh-host-keys" and "x509-certificates" if-feature 1498 statements 1500 A.6. 05 to 06 1502 * Editorial changes only. 1504 A.7. 06 to 07 1506 * Added Henk Birkholz as a co-author (thanks Henk!) 1508 * Added PSKs and raw public keys to Truststore. 1510 A.8. 07 to 08 1512 * Added new "Support for Built-in Trust Anchors" section. 1514 * Removed spurious "uses ct:trust-anchor-certs-grouping" line. 1516 * Removed PSK from model. 1518 A.9. 08 to 09 1520 * Removed remaining PSK references from text. 1522 * Wrapped each top-level list with a container. 1524 * Introduced "bag" term. 1526 * Merged "SSH Public Keys" and "Raw Public Keys" in a single "Public 1527 Keys" bag. Consuming downstream modules (i.e., "ietf-[ssh/tls]- 1528 [client/server]) refine the "public-key-format" to be either SSH 1529 or TLS specific as needed. 1531 A.10. 09 to 10 1533 * Removed "algorithm" node from examples. 1535 * Removed the no longer used statements supporting the old "ssh- 1536 public-key" and "raw-public-key" nodes. 1538 * Added a "Note to Reviewers" note to first page. 1540 A.11. 10 to 11 1542 * Corrected module prefix registered in the IANA Considerations 1543 section. 1545 * Modified 'local-or-truststore-certs-grouping' to use a list (not a 1546 leaf-list). 1548 * Added new example section "The Local or Truststore Groupings". 1550 * Clarified expected behavior for "built-in" certificates in 1551 1553 * Expanded "Data Model Overview section(s) [remove "wall" of tree 1554 diagrams]. 1556 * Updated the Security Considerations section. 1558 A.12. 11 to 12 1560 * Fixed a copy/paste issue in the "Data at Rest" Security 1561 Considerations section. 1563 Acknowledgements 1565 The authors especially thank Henk Birkholz for contributing YANG to 1566 the ietf-truststore module supporting raw public keys and PSKs (pre- 1567 shared or pairwise-symmetric keys). While these contributions were 1568 eventually replaced by reusing the existing support for asymmetric 1569 and symmetric trust anchors, respectively, it was only thru Henk's 1570 initiative that the WG was able to come to that result. 1572 The authors additionally thank the following for helping give shape 1573 to this work (ordered by first name): Balazs Kovacs, Eric Voit, 1574 Juergen Schoenwaelder, Liang Xia, Martin Bjorklund, and Nick Hancock. 1576 Author's Address 1578 Kent Watsen 1579 Watsen Networks 1581 Email: kent+ietf@watsen.net