idnits 2.17.1 draft-ietf-netconf-trust-anchors-15.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 453 has weird spacing: '...on-date yan...' == Line 460 has weird spacing: '...-format ide...' == Line 472 has weird spacing: '...on-date yan...' == Line 481 has weird spacing: '...-format ide...' == Line 495 has weird spacing: '...on-date yan...' == (3 more instances...) -- The document date (18 May 2021) is 1074 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-19 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-06 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-21 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-22 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-22 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-23 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-09 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-23 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-14 Summary: 0 errors (**), 0 flaws (~~), 16 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 18 May 2021 5 Expires: 19 November 2021 7 A YANG Data Model for a Truststore 8 draft-ietf-netconf-trust-anchors-15 10 Abstract 12 This document defines a YANG module for configuring bags of 13 certificates and bags of public keys that can be referenced by other 14 data models for trust. Notifications are sent when certificates are 15 about to expire. 17 Editorial Note (To be removed by RFC Editor) 19 This draft contains placeholder values that need to be replaced with 20 finalized values at the time of publication. This note summarizes 21 all of the substitutions that are needed. No other RFC Editor 22 instructions are specified elsewhere in this document. 24 Artwork in this document contains shorthand references to drafts in 25 progress. Please apply the following replacements: 27 * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- 28 types 30 * "BBBB" --> the assigned RFC value for this draft 32 Artwork in this document contains placeholder values for the date of 33 publication of this draft. Please apply the following replacement: 35 * "2021-05-18" --> the publication date of this draft 37 The following Appendix section is to be removed prior to publication: 39 * Appendix A. Change Log 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 19 November 2021. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Simplified BSD License text 69 as described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3 76 1.2. Specification Language . . . . . . . . . . . . . . . . . 5 77 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 78 2. The "ietf-truststore" Module . . . . . . . . . . . . . . . . 5 79 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6 80 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12 81 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 82 3. Support for Built-in Trust Anchors . . . . . . . . . . . . . 29 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 32 84 4.1. Security of Data at Rest . . . . . . . . . . . . . . . . 32 85 4.2. Unconstrained Public Key Usage . . . . . . . . . . . . . 32 86 4.3. The "ietf-truststore" YANG Module . . . . . . . . . . . . 32 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 88 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 33 89 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 33 90 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 6.1. Normative References . . . . . . . . . . . . . . . . . . 33 92 6.2. Informative References . . . . . . . . . . . . . . . . . 34 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36 94 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 36 95 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 36 96 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 36 97 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 36 98 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 36 99 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 37 100 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 37 101 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 37 102 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 37 103 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 38 104 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 38 105 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 38 106 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 38 107 A.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 38 108 A.15. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 38 109 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 112 1. Introduction 114 This document defines a YANG 1.1 [RFC7950] module having the 115 following characteristics: 117 Provide a central truststore for storing raw public keys and/or 118 certificates. 120 Provide support for storing named bags of raw public keys and/or 121 named bags of certificates. 123 Provide types that can be used to reference raw public keys or 124 certificates stored in the central truststore. 126 Provide groupings that enable raw public keys and certificates to 127 be configured locally or as references truststore instances. 129 Enable the truststore to be instantiated in other data models, in 130 addition to or in lieu of the central trusttore instance. 132 1.1. Relation to other RFCs 134 This document presents one or more YANG modules [RFC7950] that are 135 part of a collection of RFCs that work together to, ultimately, 136 enable the configuration of the clients and servers of both the 137 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 139 The modules have been defined in a modular fashion to enable their 140 use by other efforts, some of which are known to be in progress at 141 the time of this writing, with many more expected to be defined in 142 time. 144 The normative dependency relationship between the various RFCs in the 145 collection is presented in the below diagram. The labels in the 146 diagram represent the primary purpose provided by each RFC. 147 Hyperlinks to each RFC are provided below the diagram. 149 crypto-types 150 ^ ^ 151 / \ 152 / \ 153 truststore keystore 154 ^ ^ ^ ^ 155 | +---------+ | | 156 | | | | 157 | +------------+ | 158 tcp-client-server | / | | 159 ^ ^ ssh-client-server | | 160 | | ^ tls-client-server 161 | | | ^ ^ http-client-server 162 | | | | | ^ 163 | | | +-----+ +---------+ | 164 | | | | | | 165 | +-----------|--------|--------------+ | | 166 | | | | | | 167 +-----------+ | | | | | 168 | | | | | | 169 | | | | | | 170 netconf-client-server restconf-client-server 172 +=======================+===========================================+ 173 |Label in Diagram | Originating RFC | 174 +=======================+===========================================+ 175 |crypto-types | [I-D.ietf-netconf-crypto-types] | 176 +-----------------------+-------------------------------------------+ 177 |truststore | [I-D.ietf-netconf-trust-anchors] | 178 +-----------------------+-------------------------------------------+ 179 |keystore | [I-D.ietf-netconf-keystore] | 180 +-----------------------+-------------------------------------------+ 181 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 182 +-----------------------+-------------------------------------------+ 183 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 184 +-----------------------+-------------------------------------------+ 185 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 186 +-----------------------+-------------------------------------------+ 187 |http-client-server | [I-D.ietf-netconf-http-client-server] | 188 +-----------------------+-------------------------------------------+ 189 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 190 +-----------------------+-------------------------------------------+ 191 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 192 +-----------------------+-------------------------------------------+ 194 Table 1: Label to RFC Mapping 196 1.2. Specification Language 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in BCP 201 14 [RFC2119] [RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 1.3. Adherence to the NMDA 206 This document is compliant with the Network Management Datastore 207 Architecture (NMDA) [RFC8342]. For instance, trust anchors installed 208 during manufacturing (e.g., for trusted well-known services), are 209 expected to appear in (see Section 3). 211 2. The "ietf-truststore" Module 213 This section defines a YANG 1.1 [RFC7950] module that defines a 214 "truststore" and groupings supporting downstream modules to reference 215 the truststore or have locally-defined definitions. 217 This section defines a YANG 1.1 [RFC7950] module called "ietf- 218 truststore". A high-level overview of the module is provided in 219 Section 2.1. Examples illustrating the module's use are provided in 220 Examples (Section 2.2). The YANG module itself is defined in 221 Section 2.3. 223 2.1. Data Model Overview 225 This section provides an overview of the "ietf-truststore" module in 226 terms of its features, typedefs, groupings, and protocol-accessible 227 nodes. 229 2.1.1. Features 231 The following diagram lists all the "feature" statements defined in 232 the "ietf-truststore" module: 234 Features: 235 +-- central-truststore-supported 236 +-- local-definitions-supported 237 +-- certificates 238 +-- public-keys 240 | The diagram above uses syntax that is similar to but not 241 | defined in [RFC8340]. 243 2.1.2. Typedefs 245 The following diagram lists the "typedef" statements defined in the 246 "ietf-truststore" module: 248 Typedefs: 249 leafref 250 +-- certificate-bag-ref 251 +-- certificate-ref 252 +-- public-key-bag-ref 253 +-- public-key-ref 255 | The diagram above uses syntax that is similar to but not 256 | defined in [RFC8340]. 258 Comments: 260 * All of the typedefs defined in the "ietf-truststore" module extend 261 the base "leafref" type defined in [RFC7950]. 263 * The leafrefs refer to certificates, public keys, and bags in the 264 central truststore, when this module is implemented. 266 * These typedefs are provided as an aid to downstream modules that 267 import the "ietf-truststore" module. 269 2.1.3. Groupings 271 The "ietf-truststore" module defines the following "grouping" 272 statements: 274 * local-or-truststore-certs-grouping 275 * local-or-truststore-public-keys-grouping 276 * truststore-grouping 278 Each of these groupings are presented in the following subsections. 280 2.1.3.1. The "local-or-truststore-certs-grouping" Grouping 282 The following tree diagram [RFC8340] illustrates the "local-or- 283 truststore-certs-grouping" grouping: 285 grouping local-or-truststore-certs-grouping 286 +-- (local-or-truststore) 287 +--:(local) {local-definitions-supported}? 288 | +-- local-definition 289 | +-- certificate* [name] 290 | +-- name? string 291 | +---u ct:trust-anchor-cert-grouping 292 +--:(truststore) {central-truststore-supported,certificates}? 293 +-- truststore-reference? ts:certificate-bag-ref 295 Comments: 297 * The "local-or-truststore-certs-grouping" grouping is provided 298 soley as convenience to downstream modules that wish to offer an 299 option whether a bag of certificates can be defined locally or as 300 a reference to a bag in the truststore. 302 * A "choice" statement is used to expose the various options. Each 303 option is enabled by a "feature" statement. Additional "case" 304 statements MAY be augmented in if, e.g., there is a need to 305 reference a bag in an alternate location. 307 * For the "local-definition" option, the "certificate" node uses the 308 "trust-anchor-cert-grouping" grouping discussed in Section 2.1.4.7 309 of [I-D.ietf-netconf-crypto-types]. 311 * For the "truststore" option, the "truststore-reference" is an 312 instance of the "certificate-bag-ref" discussed in Section 2.1.2. 314 2.1.3.2. The "local-or-truststore-public-keys-grouping" Grouping 316 The following tree diagram [RFC8340] illustrates the "local-or- 317 truststore-public-keys-grouping" grouping: 319 grouping local-or-truststore-public-keys-grouping 320 +-- (local-or-truststore) 321 +--:(local) {local-definitions-supported}? 322 | +-- local-definition 323 | +-- public-key* [name] 324 | +-- name? string 325 | +---u ct:public-key-grouping 326 +--:(truststore) {central-truststore-supported,public-keys}? 327 +-- truststore-reference? ts:public-key-bag-ref 329 Comments: 331 * The "local-or-truststore-public-keys-grouping" grouping is 332 provided soley as convenience to downstream modules that wish to 333 offer an option whether a bag of public keys can be defined 334 locally or as a reference to a bag in the truststore. 336 * A "choice" statement is used to expose the various options. Each 337 option is enabled by a "feature" statement. Additional "case" 338 statements MAY be augmented in if, e.g., there is a need to 339 reference a bag in an alternate location. 341 * For the "local-definition" option, the "public-key" node uses the 342 "public-key-grouping" grouping discussed in Section 2.1.4.4 of 343 [I-D.ietf-netconf-crypto-types]. 345 * For the "truststore" option, the "truststore-reference" is an 346 instance of the "certificate-bag-ref" discussed in Section 2.1.2. 348 2.1.3.3. The "truststore-grouping" Grouping 350 The following tree diagram [RFC8340] illustrates the "truststore- 351 grouping" grouping: 353 grouping truststore-grouping 354 +-- certificate-bags {certificates}? 355 | +-- certificate-bag* [name] 356 | +-- name? string 357 | +-- description? string 358 | +-- certificate* [name] 359 | +-- name? string 360 | +---u ct:trust-anchor-cert-grouping 361 +-- public-key-bags {public-keys}? 362 +-- public-key-bag* [name] 363 +-- name? string 364 +-- description? string 365 +-- public-key* [name] 366 +-- name? string 367 +---u ct:public-key-grouping 369 Comments: 371 * The "truststore-grouping" grouping defines a truststore instance 372 as being composed of certificates and/or public keys, both of 373 which are enabled by "feature" statements. The structure 374 supporting certificates and public keys is essentially the same, 375 having an outer list of "bags" containing in inner list of objects 376 (certificates or public keys). The bags enable trust anchors 377 serving a common purpose to be grouped and referenced together. 379 * For certificates, each certificate is defined by the "trust- 380 anchor-cert-grouping" grouping Section 2.1.4.7 of 381 [I-D.ietf-netconf-crypto-types]. Thus the "cert-data" node is a 382 CMS structure that can be composed of a chain of one or more 383 certificates. Additionally, the "certificate-expiration" 384 notification enables the server to alert clients when certificates 385 are nearing or have already expired. 387 * For public keys, each public key is defined by the "public-key- 388 grouping" grouping Section 2.1.4.4 of 389 [I-D.ietf-netconf-crypto-types]. Thus the "public-key" node can 390 be one of any number of structures specified by the "public-key- 391 format" identity node. 393 2.1.4. Protocol-accessible Nodes 395 The following tree diagram [RFC8340] lists all the protocol- 396 accessible nodes defined in the "ietf-truststore" module, without 397 expanding the "grouping" statements: 399 module: ietf-truststore 400 +--rw truststore 401 +---u truststore-grouping 403 grouping local-or-truststore-certs-grouping 404 +-- (local-or-truststore) 405 +--:(local) {local-definitions-supported}? 406 | +-- local-definition 407 | +-- certificate* [name] 408 | +-- name? string 409 | +---u ct:trust-anchor-cert-grouping 410 +--:(truststore) {central-truststore-supported,certificates}? 411 +-- truststore-reference? ts:certificate-bag-ref 412 grouping local-or-truststore-public-keys-grouping 413 +-- (local-or-truststore) 414 +--:(local) {local-definitions-supported}? 415 | +-- local-definition 416 | +-- public-key* [name] 417 | +-- name? string 418 | +---u ct:public-key-grouping 419 +--:(truststore) {central-truststore-supported,public-keys}? 420 +-- truststore-reference? ts:public-key-bag-ref 421 grouping truststore-grouping 422 +-- certificate-bags {certificates}? 423 | +-- certificate-bag* [name] 424 | +-- name? string 425 | +-- description? string 426 | +-- certificate* [name] 427 | +-- name? string 428 | +---u ct:trust-anchor-cert-grouping 429 +-- public-key-bags {public-keys}? 430 +-- public-key-bag* [name] 431 +-- name? string 432 +-- description? string 433 +-- public-key* [name] 434 +-- name? string 435 +---u ct:public-key-grouping 437 The following tree diagram [RFC8340] lists all the protocol- 438 accessible nodes defined in the "ietf-truststore" module, with all 439 "grouping" statements expanded, enabling the truststore's full 440 structure to be seen: 442 module: ietf-truststore 443 +--rw truststore 444 +--rw certificate-bags {certificates}? 445 | +--rw certificate-bag* [name] 446 | +--rw name string 447 | +--rw description? string 448 | +--rw certificate* [name] 449 | +--rw name string 450 | +--rw cert-data trust-anchor-cert-cms 451 | +---n certificate-expiration 452 | {certificate-expiration-notification}? 453 | +-- expiration-date yang:date-and-time 454 +--rw public-key-bags {public-keys}? 455 +--rw public-key-bag* [name] 456 +--rw name string 457 +--rw description? string 458 +--rw public-key* [name] 459 +--rw name string 460 +--rw public-key-format identityref 461 +--rw public-key binary 463 grouping local-or-truststore-certs-grouping 464 +-- (local-or-truststore) 465 +--:(local) {local-definitions-supported}? 466 | +-- local-definition 467 | +-- certificate* [name] 468 | +-- name? string 469 | +-- cert-data trust-anchor-cert-cms 470 | +---n certificate-expiration 471 | {certificate-expiration-notification}? 472 | +-- expiration-date yang:date-and-time 473 +--:(truststore) {central-truststore-supported,certificates}? 474 +-- truststore-reference? ts:certificate-bag-ref 475 grouping local-or-truststore-public-keys-grouping 476 +-- (local-or-truststore) 477 +--:(local) {local-definitions-supported}? 478 | +-- local-definition 479 | +-- public-key* [name] 480 | +-- name? string 481 | +-- public-key-format identityref 482 | +-- public-key binary 483 +--:(truststore) {central-truststore-supported,public-keys}? 484 +-- truststore-reference? ts:public-key-bag-ref 485 grouping truststore-grouping 486 +-- certificate-bags {certificates}? 487 | +-- certificate-bag* [name] 488 | +-- name? string 489 | +-- description? string 490 | +-- certificate* [name] 491 | +-- name? string 492 | +-- cert-data trust-anchor-cert-cms 493 | +---n certificate-expiration 494 | {certificate-expiration-notification}? 495 | +-- expiration-date yang:date-and-time 496 +-- public-key-bags {public-keys}? 497 +-- public-key-bag* [name] 498 +-- name? string 499 +-- description? string 500 +-- public-key* [name] 501 +-- name? string 502 +-- public-key-format identityref 503 +-- public-key binary 505 Comments: 507 * Protocol-accessible nodes are those nodes that are accessible when 508 the module is "implemented", as described in Section 5.6.5 of 509 [RFC7950]. 511 * The protcol-accessible nodes for the "ietf-truststore" module are 512 an instance of the "truststore-grouping" grouping discussed in 513 Section 2.1.3.3. 515 * The reason for why the "truststore-grouping" exists separate from 516 the protocol-accessible nodes definition is to enable instances of 517 the truststore to be instantiated in other locations, as may be 518 needed or desired by some modules. 520 2.2. Example Usage 522 The examples in this section are encoded using XML, such as might be 523 the case when using the NETCONF protocol. Other encodings MAY be 524 used, such as JSON when using the RESTCONF protocol. 526 2.2.1. A Truststore Instance 528 This section presents an example illustrating trust anchors in 529 , as per Section 2.1.4. Please see Section 3 for an 530 example illustrating built-in values in . 532 The example contained in this section defines eight bags of trust 533 anchors. There are four certificate-based bags and four public key 534 based bags. The following diagram provides an overview of the 535 contents in the example: 537 Certificate Bags 538 +-- Trust anchor certs for authenticating a set of remote servers 539 +-- End entity certs for authenticating a set of remote servers 540 +-- Trust anchor certs for authenticating a set of remote clients 541 +-- End entity certs for authenticating a set of remote clients 543 Public Key Bags 544 +-- SSH keys to authenticate a set of remote SSH server 545 +-- SSH keys to authenticate a set of remote SSH clients 546 +-- Raw public keys to authenticate a set of remote SSH server 547 +-- Raw public keys to authenticate a set of remote SSH clients 549 Following is the full example: 551 555 556 558 559 560 trusted-server-ca-certs 561 562 Trust anchors (i.e. CA certs) used to authenticate server 563 certificates. A server certificate is authenticated if its 564 end-entity certificate has a chain of trust to one of these 565 certificates. 566 567 568 Server Cert Issuer #1 569 base64encodedvalue== 570 571 572 Server Cert Issuer #2 573 base64encodedvalue== 574 575 577 578 579 trusted-server-ee-certs 580 581 Specific end-entity certificates used to authenticate server 582 certificates. A server certificate is authenticated if its 583 end-entity certificate is an exact match to one of these 584 certificates. 586 587 588 My Application #1 589 base64encodedvalue== 590 591 592 My Application #2 593 base64encodedvalue== 594 595 597 598 599 trusted-client-ca-certs 600 601 Trust anchors (i.e. CA certs) used to authenticate client 602 certificates. A client certificate is authenticated if its 603 end-entity certificate has a chain of trust to one of these 604 certificates. 605 606 607 Client Identity Issuer #1 608 base64encodedvalue== 609 610 611 Client Identity Issuer #2 612 base64encodedvalue== 613 614 616 617 618 trusted-client-ee-certs 619 620 Specific end-entity certificates used to authenticate client 621 certificates. A client certificate is authenticated if its 622 end-entity certificate is an exact match to one of these 623 certificates. 624 625 626 George Jetson 627 base64encodedvalue== 628 629 630 Fred Flintstone 631 base64encodedvalue== 632 633 635 637 638 640 641 642 trusted-ssh-public-keys 643 644 Specific SSH public keys used to authenticate SSH server 645 public keys. An SSH server public key is authenticated if 646 its public key is an exact match to one of these public keys. 648 This list of SSH public keys is analogous to OpenSSH's 649 "/etc/ssh/ssh_known_hosts" file. 650 651 652 corp-fw1 653 654 ct:ssh-public-key-format 655 656 base64encodedvalue== 657 658 659 corp-fw2 660 661 ct:ssh-public-key-format 662 663 base64encodedvalue== 664 665 667 668 669 SSH Public Keys for Application A 670 671 SSH public keys used to authenticate application A's SSH 672 public keys. An SSH public key is authenticated if it 673 is an exact match to one of these public keys. 674 675 676 Application Instance #1 677 678 ct:ssh-public-key-format 679 680 base64encodedvalue== 681 682 683 Application Instance #2 684 685 ct:ssh-public-key-format 686 687 base64encodedvalue== 688 689 691 692 693 Raw Public Keys for TLS Servers 694 695 Raw Public Key #1 696 697 ct:subject-public-key-info-format 698 base64encodedvalue== 699 700 701 Raw Public Key #2 702 703 ct:subject-public-key-info-format 704 705 base64encodedvalue== 706 707 709 710 711 Raw Public Keys for TLS Clients 712 713 Raw Public Key #1 714 715 ct:subject-public-key-info-format 716 717 base64encodedvalue== 718 719 720 Raw Public Key #2 721 722 ct:subject-public-key-info-format 723 724 base64encodedvalue== 725 726 727 728 730 2.2.2. A Certificate Expiration Notification 732 The following example illustrates the "certificate-expiration" 733 notification (per Section 2.1.4.6 of [I-D.ietf-netconf-crypto-types]) 734 for a certificate configured in the truststore in Section 2.2.1. 736 =============== NOTE: '\' line wrapping per RFC 8792 ================ 738 740 2018-05-25T00:01:00Z 741 742 743 744 trusted-client-ee-certs 745 746 George Jetson 747 748 2018-08-05T14:18:53-05:00 750 751 752 753 754 755 757 2.2.3. The "Local or Truststore" Groupings 759 This section illustrates the various "local-or-truststore" groupings 760 defined in the "ietf-truststore" module, specifically the "local-or- 761 truststore-certs-grouping" (Section 2.1.3.1) and "local-or- 762 truststore-public-keys-grouping" (Section 2.1.3.2) groupings. 764 These examples assume the existence of an example module called "ex- 765 truststore-usage" having the namespace "http://example.com/ns/ 766 example-truststore-usage". 768 The ex-truststore-usage module is first presented using tree diagrams 769 [RFC8340], followed by an instance example illustrating all the 770 "local-or-truststore" groupings in use, followed by the YANG module 771 itself. 773 The following tree diagram illustrates "ex-truststore-usage" without 774 expanding the "grouping" statements: 776 module: ex-truststore-usage 777 +--rw truststore-usage 778 +--rw cert* [name] 779 | +--rw name string 780 | +---u ts:local-or-truststore-certs-grouping 781 +--rw public-key* [name] 782 +--rw name string 783 +---u ts:local-or-truststore-public-keys-grouping 785 The following tree diagram illustrates the "ex-truststore-usage" 786 module, with all "grouping" statements expanded, enabling the 787 truststore's full structure to be seen: 789 module: ex-truststore-usage 790 +--rw truststore-usage 791 +--rw cert* [name] 792 | +--rw name string 793 | +--rw (local-or-truststore) 794 | +--:(local) {local-definitions-supported}? 795 | | +--rw local-definition 796 | | +--rw certificate* [name] 797 | | +--rw name string 798 | | +--rw cert-data 799 | | | trust-anchor-cert-cms 800 | | +---n certificate-expiration 801 | | {certificate-expiration-notification}? 802 | | +-- expiration-date yang:date-and-time 803 | +--:(truststore) 804 | {central-truststore-supported,certificates}? 805 | +--rw truststore-reference? ts:certificate-bag-ref 806 +--rw public-key* [name] 807 +--rw name string 808 +--rw (local-or-truststore) 809 +--:(local) {local-definitions-supported}? 810 | +--rw local-definition 811 | +--rw public-key* [name] 812 | +--rw name string 813 | +--rw public-key-format identityref 814 | +--rw public-key binary 815 +--:(truststore) 816 {central-truststore-supported,public-keys}? 817 +--rw truststore-reference? ts:public-key-bag-ref 819 The following example provides two equivalent instances of each 820 grouping, the first being a reference to a truststore and the second 821 being locally-defined. The instance having a reference to a 822 truststore is consistent with the truststore defined in 823 Section 2.2.1. The two instances are equivalent, as the locally- 824 defined instance example contains the same values defined by the 825 truststore instance referenced by its sibling example. 827 =============== NOTE: '\' line wrapping per RFC 8792 ================ 829 833 834 836 837 example 1a 838 trusted-client-ca-certs 840 842 843 example 1b 844 845 my-trusted-client-ca-certs 846 847 Client Identity Issuer #1 848 base64encodedvalue== 849 850 851 Client Identity Issuer #2 852 base64encodedvalue== 853 854 855 857 858 860 861 example 2a 862 trusted-ssh-public-keys 864 865 866 example 2b 867 868 trusted-ssh-public-keys 869 870 corp-fw1 871 872 ct:ssh-public-key-format 873 874 base64encodedvalue== 875 876 877 corp-fw2 878 879 ct:ssh-public-key-format 880 881 base64encodedvalue== 882 883 884 886 888 Following is the "ex-truststore-usage" module's YANG definition: 890 module ex-truststore-usage { 891 yang-version 1.1; 892 namespace "http://example.com/ns/example-truststore-usage"; 893 prefix etu; 895 import ietf-truststore { 896 prefix ts; 897 reference 898 "RFC BBBB: A YANG Data Model for a Truststore"; 899 } 901 organization 902 "Example Corporation"; 904 contact 905 "Author: YANG Designer "; 907 description 908 "This module illustrates notable groupings defined in 909 the 'ietf-truststore' module."; 911 revision 2021-05-18 { 912 description 913 "Initial version"; 914 reference 915 "RFC BBBB: A YANG Data Model for a Truststore"; 916 } 918 container truststore-usage { 919 description 920 "An illustration of the various truststore groupings."; 921 list cert { 922 key "name"; 923 leaf name { 924 type string; 925 description 926 "An arbitrary name for this cert."; 927 } 928 uses ts:local-or-truststore-certs-grouping; 929 description 930 "An cert that may be configured locally or be 931 a reference to a cert in the truststore."; 932 } 933 list public-key { 934 key "name"; 935 leaf name { 936 type string; 937 description 938 "An arbitrary name for this cert."; 939 } 940 uses ts:local-or-truststore-public-keys-grouping; 941 description 942 "An public key that may be configured locally or be 943 a reference to a public key in the truststore."; 944 } 945 } 946 } 948 2.3. YANG Module 950 This YANG module imports modules from [RFC8341] and 951 [I-D.ietf-netconf-crypto-types]. 953 file "ietf-truststore@2021-05-18.yang" 955 module ietf-truststore { 956 yang-version 1.1; 957 namespace "urn:ietf:params:xml:ns:yang:ietf-truststore"; 958 prefix ts; 960 import ietf-netconf-acm { 961 prefix nacm; 962 reference 963 "RFC 8341: Network Configuration Access Control Model"; 964 } 966 import ietf-crypto-types { 967 prefix ct; 968 reference 969 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 970 } 972 organization 973 "IETF NETCONF (Network Configuration) Working Group"; 975 contact 976 "WG Web : 977 WG List : 978 Author : Kent Watsen "; 980 description 981 "This module defines a 'truststore' to centralize management 982 of trust anchors including certificates and public keys. 984 Copyright (c) 2021 IETF Trust and the persons identified 985 as authors of the code. All rights reserved. 987 Redistribution and use in source and binary forms, with 988 or without modification, is permitted pursuant to, and 989 subject to the license terms contained in, the Simplified 990 BSD License set forth in Section 4.c of the IETF Trust's 991 Legal Provisions Relating to IETF Documents 992 (https://trustee.ietf.org/license-info). 994 This version of this YANG module is part of RFC BBBB 995 (https://www.rfc-editor.org/info/rfcBBBB); see the RFC 996 itself for full legal notices. 998 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 999 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1000 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1001 are to be interpreted as described in BCP 14 (RFC 2119) 1002 (RFC 8174) when, and only when, they appear in all 1003 capitals, as shown here."; 1005 revision 2021-05-18 { 1006 description 1007 "Initial version"; 1008 reference 1009 "RFC BBBB: A YANG Data Model for a Truststore"; 1010 } 1012 /****************/ 1013 /* Features */ 1014 /****************/ 1016 feature central-truststore-supported { 1017 description 1018 "The 'central-truststore-supported' feature indicates that 1019 the server supports the truststore (i.e., implements the 1020 'ietf-truststore' module)."; 1021 } 1023 feature local-definitions-supported { 1024 description 1025 "The 'local-definitions-supported' feature indicates that 1026 the server supports locally-defined trust anchors."; 1027 } 1029 feature certificates { 1030 description 1031 "The 'certificates' feature indicates that the server 1032 implements the /truststore/certificate-bags subtree."; 1033 } 1035 feature public-keys { 1036 description 1037 "The 'public-keys' feature indicates that the server 1038 implements the /truststore/public-key-bags subtree."; 1039 } 1041 /****************/ 1042 /* Typedefs */ 1043 /****************/ 1045 typedef certificate-bag-ref { 1046 type leafref { 1047 path "/ts:truststore/ts:certificate-bags/" 1048 + "ts:certificate-bag/ts:name"; 1049 } 1050 description 1051 "This typedef defines a reference to a certificate bag 1052 in the truststore, when this module is implemented."; 1053 } 1055 typedef certificate-ref { 1056 type leafref { 1057 path "/ts:truststore/ts:certificate-bags/ts:certificate-bag" 1058 + "[ts:name = current()/../ts:certificate-bag]/" 1059 + "ts:certificate/ts:name"; 1060 } 1061 description 1062 "This typedef defines a reference to a specific certificate 1063 in a certificate bag in the truststore, when this module 1064 is implemented. This typedef requires that there exist a 1065 sibling 'leaf' node called 'certificate-bag' that SHOULD 1066 have the typedef 'certificate-bag-ref'."; 1067 } 1069 typedef public-key-bag-ref { 1070 type leafref { 1071 path "/ts:truststore/ts:public-key-bags/" 1072 + "ts:public-key-bag/ts:name"; 1073 } 1074 description 1075 "This typedef defines a reference to a public key bag 1076 in the truststore, when this module is implemented."; 1077 } 1079 typedef public-key-ref { 1080 type leafref { 1081 path "/ts:truststore/ts:public-key-bags/ts:public-key-bag" 1082 + "[ts:name = current()/../ts:public-key-bag]/" 1083 + "ts:public-key/ts:name"; 1084 } 1085 description 1086 "This typedef defines a reference to a specific public key 1087 in a public key bag in the truststore, when this module is 1088 implemented. This typedef requires that there exist a 1089 sibling 'leaf' node called 'public-key-bag' that SHOULD 1090 have the typedef 'public-key-bag-ref'."; 1091 } 1093 /*****************/ 1094 /* Groupings */ 1095 /*****************/ 1097 grouping local-or-truststore-certs-grouping { 1098 description 1099 "A grouping that allows the certificates to be either 1100 configured locally, within the using data model, or be a 1101 reference to a certificate bag stored in the truststore. 1103 Servers that do not 'implement' this module, and hence 1104 'central-truststore-supported' is not defined, SHOULD 1105 augment in custom 'case' statements enabling references 1106 to the alternate truststore locations."; 1107 choice local-or-truststore { 1108 nacm:default-deny-write; 1109 mandatory true; 1110 description 1111 "A choice between an inlined definition and a definition 1112 that exists in the truststore."; 1113 case local { 1114 if-feature "local-definitions-supported"; 1115 container local-definition { 1116 description 1117 "A container for locally configured trust anchor 1118 certificates."; 1119 list certificate { 1120 key "name"; 1121 min-elements 1; 1122 description 1123 "A trust anchor certificate."; 1124 leaf name { 1125 type string; 1126 description 1127 "An arbitrary name for this certificate."; 1128 } 1129 uses ct:trust-anchor-cert-grouping { 1130 refine "cert-data" { 1131 mandatory true; 1132 } 1133 } 1134 } 1135 } 1136 } 1137 case truststore { 1138 if-feature "central-truststore-supported"; 1139 if-feature "certificates"; 1140 leaf truststore-reference { 1141 type ts:certificate-bag-ref; 1142 description 1143 "A reference to a certificate bag that exists in the 1144 truststore, when this module is implemented."; 1145 } 1146 } 1147 } 1148 } 1150 grouping local-or-truststore-public-keys-grouping { 1151 description 1152 "A grouping that allows the public keys to be either 1153 configured locally, within the using data model, or be a 1154 reference to a public key bag stored in the truststore. 1156 Servers that do not 'implement' this module, and hence 1157 'central-truststore-supported' is not defined, SHOULD 1158 augment in custom 'case' statements enabling references 1159 to the alternate truststore locations."; 1160 choice local-or-truststore { 1161 nacm:default-deny-write; 1162 mandatory true; 1163 description 1164 "A choice between an inlined definition and a definition 1165 that exists in the truststore."; 1166 case local { 1167 if-feature "local-definitions-supported"; 1168 container local-definition { 1169 description 1170 "A container to hold local public key definitions."; 1171 list public-key { 1172 key "name"; 1173 description 1174 "A public key definition."; 1175 leaf name { 1176 type string; 1177 description 1178 "An arbitrary name for this public key."; 1179 } 1180 uses ct:public-key-grouping; 1181 } 1182 } 1183 } 1184 case truststore { 1185 if-feature "central-truststore-supported"; 1186 if-feature "public-keys"; 1187 leaf truststore-reference { 1188 type ts:public-key-bag-ref; 1189 description 1190 "A reference to a bag of public keys that exists 1191 in the truststore, when this module is implemented."; 1192 } 1193 } 1194 } 1195 } 1197 grouping truststore-grouping { 1198 description 1199 "A grouping definition that enables use in other contexts. 1200 Where used, implementations MUST augment new 'case' 1201 statements into the various local-or-truststore 'choice' 1202 statements to supply leafrefs to the model-specific 1203 location(s)."; 1204 container certificate-bags { 1205 nacm:default-deny-write; 1206 if-feature "certificates"; 1207 description 1208 "A collection of certificate bags."; 1209 list certificate-bag { 1210 key "name"; 1211 description 1212 "A bag of certificates. Each bag of certificates SHOULD 1213 be for a specific purpose. For instance, one bag could 1214 be used to authenticate a specific set of servers, while 1215 another could be used to authenticate a specific set of 1216 clients."; 1217 leaf name { 1218 type string; 1219 description 1220 "An arbitrary name for this bag of certificates."; 1221 } 1222 leaf description { 1223 type string; 1224 description 1225 "A description for this bag of certificates. The 1226 intended purpose for the bag SHOULD be described."; 1227 } 1228 list certificate { 1229 key "name"; 1230 description 1231 "A trust anchor certificate."; 1232 leaf name { 1233 type string; 1234 description 1235 "An arbitrary name for this certificate."; 1236 } 1237 uses ct:trust-anchor-cert-grouping { 1238 refine "cert-data" { 1239 mandatory true; 1240 } 1241 } 1242 } 1243 } 1244 } 1245 container public-key-bags { 1246 nacm:default-deny-write; 1247 if-feature "public-keys"; 1248 description 1249 "A collection of public key bags."; 1250 list public-key-bag { 1251 key "name"; 1252 description 1253 "A bag of public keys. Each bag of keys SHOULD be for 1254 a specific purpose. For instance, one bag could be used 1255 authenticate a specific set of servers, while another 1256 could be used to authenticate a specific set of clients."; 1257 leaf name { 1258 type string; 1259 description 1260 "An arbitrary name for this bag of public keys."; 1261 } 1262 leaf description { 1263 type string; 1264 description 1265 "A description for this bag public keys. The 1266 intended purpose for the bag SHOULD be described."; 1267 } 1268 list public-key { 1269 key "name"; 1270 description 1271 "A public key."; 1272 leaf name { 1273 type string; 1274 description 1275 "An arbitrary name for this public key."; 1276 } 1277 uses ct:public-key-grouping; 1278 } 1279 } 1280 } 1281 } 1283 /*********************************/ 1284 /* Protocol accessible nodes */ 1285 /*********************************/ 1287 container truststore { 1288 nacm:default-deny-write; 1289 description 1290 "The truststore contains bags of certificates and 1291 public keys."; 1292 uses truststore-grouping; 1293 } 1294 } 1296 1298 3. Support for Built-in Trust Anchors 1300 In some implementations, a server may define some built-in trust 1301 anchors. For instance, there may be built-in trust anchors enabling 1302 the server to securely connect to well-known services (e.g., an SZTP 1303 [RFC8572] bootstrap server) or public CA certificates to connect to 1304 arbitrary services using public PKI. 1306 Built-in trust anchors are expected to be set by a vendor-specific 1307 process. Any ability for operators to modify built-in trust anchors 1308 is outside the scope of this document. 1310 As built-in trust anchors are provided by the server, they are 1311 present in . The example below illustrates what the 1312 truststore in might look like for a server in its 1313 factory default state. 1315 1320 1322 1323 Built-In Manufacturer Trust Anchor Certificates 1324 1325 Certificates built into the device for authenticating 1326 manufacturer-signed objects, such as TLS server certificates, 1327 vouchers, etc. 1328 1329 1330 Manufacturer Root CA Cert 1331 base64encodedvalue== 1332 1333 1335 1336 Built-In Public Trust Anchor Certificates 1337 1338 Certificates built into the device for authenticating 1339 certificates issued by public certificate authorities, 1340 such as the end-entity certificate for web servers. 1341 1342 1343 Public Root CA Cert 1 1344 base64encodedvalue== 1345 1346 1347 Public Root CA Cert 2 1348 base64encodedvalue== 1349 1350 1351 Public Root CA Cert 3 1352 base64encodedvalue== 1353 1354 1356 1357 1359 In order for the built-in bags of trust anchors and/or their trust 1360 anchors to be referenced by configuration, they MUST first be copied 1361 into . 1363 The built-in bags and/or their trust anchors MUST be copied into 1364 using the same "key" values if it is desired for the server 1365 to maintain/update them (e.g., a software update may update a bag of 1366 trusted public CA certificates used for TLS-client connections). 1368 Built-in bags and/or their trust anchors MAY be copied into other 1369 parts of the configuration but, by doing so, they lose their 1370 association to the built-in entries and any assurances afforded by 1371 knowing they are/were built-in. 1373 The built-in bags and/or their trust anchors are immutable by 1374 configuration operations. Servers MUST ignore attempts to modify any 1375 aspect of built-in bags and/or their trust anchors from . 1377 The following example illustrates how a single built-in public CA 1378 certificate from the previous example has been propagated to 1379 : 1381 1384 1386 1387 Built-In Public Trust Anchor Certificates 1388 1389 Certificates built into the device for authenticating 1390 certificates issued by public certificate authorities, 1391 such as the end-entity certificate for web servers. 1393 Only the subset of the certificates that are referenced 1394 by other configuration nodes need to be copied. For 1395 instance, only "Public Root CA Cert 3" is present here. 1397 No new certificates can be added, nor existing certificate 1398 values changed. Missing certificates have no effect on 1399 "operational" when the configuration is applied. 1400 1401 1402 Public Root CA Cert 3 1403 base64encodedvalue== 1404 1405 1407 1408 1410 4. Security Considerations 1412 4.1. Security of Data at Rest 1414 The YANG module defined in this document defines a mechanism called a 1415 "truststore" that, by its name, suggests that its contents are 1416 protected from unauthorized modification. 1418 Security controls for the API (i.e., data in motion) are discussed in 1419 Section 4.3, but controls for the data at rest cannot be specified by 1420 the YANG module. 1422 In order to satisfy the expectations of a "truststore", it is 1423 RECOMMENDED that implementations ensure that the truststore contents 1424 are protected from unauthorized modifications when at rest. 1426 4.2. Unconstrained Public Key Usage 1428 This module enables the configuration of public keys without 1429 constraints on their usage, e.g., what operations the key is allowed 1430 to be used for (encryption, verification, both). 1432 This module also enables the configuration of certificates, where 1433 each certificate may constrain the usage of the public key according 1434 to local policy. 1436 4.3. The "ietf-truststore" YANG Module 1438 The YANG module defined in this document is designed to be accessed 1439 via YANG based management protocols, such as NETCONF [RFC6241] and 1440 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1441 implement secure transport layers (e.g., SSH, TLS) with mutual 1442 authentication. 1444 The NETCONF access control model (NACM) [RFC8341] provides the means 1445 to restrict access for particular users to a pre-configured subset of 1446 all available protocol operations and content. 1448 None of the readable data nodes defined in this YANG module are 1449 considered sensitive or vulnerable in network environments. The NACM 1450 "default-deny-all" extension has not been set for any data nodes 1451 defined in this module. 1453 All of the writable data nodes defined by this module, both in the 1454 "grouping" statements as well as the protocol-accessible "truststore" 1455 instance, may be considered sensitive or vulnerable in some network 1456 environments. For instance, any modification to a trust anchor or 1457 reference to a trust anchor may dramatically alter the implemented 1458 security policy. For this reason, the NACM extension "default-deny- 1459 write" has been set for all data nodes defined in this module. 1461 This module does not define any "rpc" or "action" statements, and 1462 thus the security considerations for such is not provided here. 1464 5. IANA Considerations 1466 5.1. The "IETF XML" Registry 1468 This document registers one URI in the "ns" subregistry of the IETF 1469 XML Registry [RFC3688]. Following the format in [RFC3688], the 1470 following registration is requested: 1472 URI: urn:ietf:params:xml:ns:yang:ietf-truststore 1473 Registrant Contact: The IESG 1474 XML: N/A, the requested URI is an XML namespace. 1476 5.2. The "YANG Module Names" Registry 1478 This document registers one YANG module in the YANG Module Names 1479 registry [RFC6020]. Following the format in [RFC6020], the following 1480 registration is requested: 1482 name: ietf-truststore 1483 namespace: urn:ietf:params:xml:ns:yang:ietf-truststore 1484 prefix: ts 1485 reference: RFC BBBB 1487 6. References 1489 6.1. Normative References 1491 [I-D.ietf-netconf-crypto-types] 1492 Watsen, K., "YANG Data Types and Groupings for 1493 Cryptography", Work in Progress, Internet-Draft, draft- 1494 ietf-netconf-crypto-types-19, 10 February 2021, 1495 . 1498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1499 Requirement Levels", BCP 14, RFC 2119, 1500 DOI 10.17487/RFC2119, March 1997, 1501 . 1503 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1504 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1505 . 1507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1508 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1509 May 2017, . 1511 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1512 Access Control Model", STD 91, RFC 8341, 1513 DOI 10.17487/RFC8341, March 2018, 1514 . 1516 6.2. Informative References 1518 [I-D.ietf-netconf-http-client-server] 1519 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 1520 Servers", Work in Progress, Internet-Draft, draft-ietf- 1521 netconf-http-client-server-06, 10 February 2021, 1522 . 1525 [I-D.ietf-netconf-keystore] 1526 Watsen, K., "A YANG Data Model for a Keystore", Work in 1527 Progress, Internet-Draft, draft-ietf-netconf-keystore-21, 1528 10 February 2021, . 1531 [I-D.ietf-netconf-netconf-client-server] 1532 Watsen, K., "NETCONF Client and Server Models", Work in 1533 Progress, Internet-Draft, draft-ietf-netconf-netconf- 1534 client-server-22, 10 February 2021, 1535 . 1538 [I-D.ietf-netconf-restconf-client-server] 1539 Watsen, K., "RESTCONF Client and Server Models", Work in 1540 Progress, Internet-Draft, draft-ietf-netconf-restconf- 1541 client-server-22, 10 February 2021, 1542 . 1545 [I-D.ietf-netconf-ssh-client-server] 1546 Watsen, K., "YANG Groupings for SSH Clients and SSH 1547 Servers", Work in Progress, Internet-Draft, draft-ietf- 1548 netconf-ssh-client-server-23, 10 February 2021, 1549 . 1552 [I-D.ietf-netconf-tcp-client-server] 1553 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 1554 and TCP Servers", Work in Progress, Internet-Draft, draft- 1555 ietf-netconf-tcp-client-server-09, 10 February 2021, 1556 . 1559 [I-D.ietf-netconf-tls-client-server] 1560 Watsen, K., "YANG Groupings for TLS Clients and TLS 1561 Servers", Work in Progress, Internet-Draft, draft-ietf- 1562 netconf-tls-client-server-23, 10 February 2021, 1563 . 1566 [I-D.ietf-netconf-trust-anchors] 1567 Watsen, K., "A YANG Data Model for a Truststore", Work in 1568 Progress, Internet-Draft, draft-ietf-netconf-trust- 1569 anchors-14, 10 February 2021, 1570 . 1573 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1574 DOI 10.17487/RFC3688, January 2004, 1575 . 1577 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1578 the Network Configuration Protocol (NETCONF)", RFC 6020, 1579 DOI 10.17487/RFC6020, October 2010, 1580 . 1582 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1583 and A. Bierman, Ed., "Network Configuration Protocol 1584 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1585 . 1587 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1588 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1589 . 1591 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1592 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1593 . 1595 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1596 and R. Wilton, "Network Management Datastore Architecture 1597 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1598 . 1600 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1601 Touch Provisioning (SZTP)", RFC 8572, 1602 DOI 10.17487/RFC8572, April 2019, 1603 . 1605 Appendix A. Change Log 1607 This section is to be removed before publishing as an RFC. 1609 A.1. 00 to 01 1611 * Added features "x509-certificates" and "ssh-host-keys". 1613 * Added nacm:default-deny-write to "trust-anchors" container. 1615 A.2. 01 to 02 1617 * Switched "list pinned-certificate" to use the "trust-anchor-cert- 1618 grouping" from crypto-types. Effectively the same definition as 1619 before. 1621 A.3. 02 to 03 1623 * Updated copyright date, boilerplate template, affiliation, folding 1624 algorithm, and reformatted the YANG module. 1626 A.4. 03 to 04 1628 * Added groupings 'local-or-truststore-certs-grouping' and 'local- 1629 or-truststore-host-keys-grouping', matching similar definitions in 1630 the keystore draft. Note new (and incomplete) "truststore" usage! 1632 * Related to above, also added features 'truststore-supported' and 1633 'local-trust-anchors-supported'. 1635 A.5. 04 to 05 1637 * Renamed "trust-anchors" to "truststore" 1638 * Removed "pinned." prefix everywhere, to match truststore rename 1640 * Moved everything under a top-level 'grouping' to enable use in 1641 other contexts. 1643 * Renamed feature from 'local-trust-anchors-supported' to 'local- 1644 definitions-supported' (same name used in keystore) 1646 * Removed the "require-instance false" statement from the "*-ref" 1647 typedefs. 1649 * Added missing "ssh-host-keys" and "x509-certificates" if-feature 1650 statements 1652 A.6. 05 to 06 1654 * Editorial changes only. 1656 A.7. 06 to 07 1658 * Added Henk Birkholz as a co-author (thanks Henk!) 1660 * Added PSKs and raw public keys to truststore. 1662 A.8. 07 to 08 1664 * Added new "Support for Built-in Trust Anchors" section. 1666 * Removed spurious "uses ct:trust-anchor-certs-grouping" line. 1668 * Removed PSK from model. 1670 A.9. 08 to 09 1672 * Removed remaining PSK references from text. 1674 * Wrapped each top-level list with a container. 1676 * Introduced "bag" term. 1678 * Merged "SSH Public Keys" and "Raw Public Keys" in a single "Public 1679 Keys" bag. Consuming downstream modules (i.e., "ietf-[ssh/tls]- 1680 [client/server]) refine the "public-key-format" to be either SSH 1681 or TLS specific as needed. 1683 A.10. 09 to 10 1685 * Removed "algorithm" node from examples. 1687 * Removed the no longer used statements supporting the old "ssh- 1688 public-key" and "raw-public-key" nodes. 1690 * Added a "Note to Reviewers" note to first page. 1692 A.11. 10 to 11 1694 * Corrected module prefix registered in the IANA Considerations 1695 section. 1697 * Modified 'local-or-truststore-certs-grouping' to use a list (not a 1698 leaf-list). 1700 * Added new example section "The Local or Truststore Groupings". 1702 * Clarified expected behavior for "built-in" certificates in 1703 1705 * Expanded "Data Model Overview section(s) [remove "wall" of tree 1706 diagrams]. 1708 * Updated the Security Considerations section. 1710 A.12. 11 to 12 1712 * Fixed a copy/paste issue in the "Data at Rest" Security 1713 Considerations section. 1715 A.13. 12 to 13 1717 * Fixed issues found by the SecDir review of the "keystore" draft. 1719 A.14. 13 to 14 1721 * Added an "Unconstrained Public Key Usage" Security Consideration 1722 to address concern raised by SecDir. 1724 * Addressed comments raised by YANG Doctor. 1726 A.15. 14 to 15 1728 * Added prefixes to 'path' statements per trust-anchors/issues/1 1729 * Renamed feature "truststore-supported" to "central-truststore- 1730 supported". 1732 * Associated with above, generally moved text to refer to a 1733 "central" truststore. 1735 * Removed two unecessary/unwanted "min-elements 1" and associated 1736 "presence" statements. 1738 * Aligned modules with `pyang -f` formatting. 1740 * Fixed nits found by YANG Doctor reviews. 1742 Acknowledgements 1744 The authors especially thank Henk Birkholz for contributing YANG to 1745 the ietf-truststore module supporting raw public keys and PSKs (pre- 1746 shared or pairwise-symmetric keys). While these contributions were 1747 eventually replaced by reusing the existing support for asymmetric 1748 and symmetric trust anchors, respectively, it was only thru Henk's 1749 initiative that the WG was able to come to that result. 1751 The authors additionally thank the following for helping give shape 1752 to this work (ordered by first name): Balazs Kovacs, Eric Voit, 1753 Juergen Schoenwaelder, Liang Xia, Martin Bjoerklund, Nick Hancock, 1754 and Yoav Nir. 1756 Author's Address 1758 Kent Watsen 1759 Watsen Networks 1761 Email: kent+ietf@watsen.net