idnits 2.17.1 draft-ietf-netconf-trust-anchors-17.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 465 has weird spacing: '...on-date yan...' == Line 472 has weird spacing: '...-format ide...' == Line 484 has weird spacing: '...on-date yan...' == Line 493 has weird spacing: '...-format ide...' == Line 507 has weird spacing: '...on-date yan...' == (3 more instances...) -- The document date (7 March 2022) is 753 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-21 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-08 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-23 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-24 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-24 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-26 == Outdated reference: A later version (-24) exists of draft-ietf-netconf-tcp-client-server-11 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-26 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-16 == Outdated reference: A later version (-05) exists of draft-ma-netmod-with-system-02 Summary: 0 errors (**), 0 flaws (~~), 17 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 7 March 2022 5 Expires: 8 September 2022 7 A YANG Data Model for a Truststore 8 draft-ietf-netconf-trust-anchors-17 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 * 2022-03-07 --> 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 8 September 2022. 58 Copyright Notice 60 Copyright (c) 2022 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 Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised 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 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 79 2. The "ietf-truststore" Module . . . . . . . . . . . . . . . . 6 80 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6 81 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12 82 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 83 3. Support for Built-in Trust Anchors . . . . . . . . . . . . . 29 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 32 85 4.1. Security of Data at Rest . . . . . . . . . . . . . . . . 32 86 4.2. Unconstrained Public Key Usage . . . . . . . . . . . . . 32 87 4.3. The "ietf-truststore" YANG Module . . . . . . . . . . . . 32 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 89 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 33 90 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 33 91 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 92 6.1. Normative References . . . . . . . . . . . . . . . . . . 33 93 6.2. Informative References . . . . . . . . . . . . . . . . . 34 95 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36 96 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 36 97 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 36 98 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 36 99 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 36 100 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 37 101 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 37 102 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 37 103 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 37 104 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 37 105 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 38 106 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 38 107 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 38 108 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 38 109 A.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 38 110 A.15. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 38 111 A.16. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 39 112 A.17. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 39 113 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39 114 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 116 1. Introduction 118 This document defines a YANG 1.1 [RFC7950] module having the 119 following characteristics: 121 Provide a central truststore for storing raw public keys and/or 122 certificates. 124 Provide support for storing named bags of raw public keys and/or 125 named bags of certificates. 127 Provide types that can be used to reference raw public keys or 128 certificates stored in the central truststore. 130 Provide groupings that enable raw public keys and certificates to 131 be configured locally or as references truststore instances. 133 Enable the truststore to be instantiated in other data models, in 134 addition to or in lieu of the central trusttore instance. 136 1.1. Relation to other RFCs 138 This document presents one or more YANG modules [RFC7950] that are 139 part of a collection of RFCs that work together to, ultimately, 140 enable the configuration of the clients and servers of both the 141 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 143 The modules have been defined in a modular fashion to enable their 144 use by other efforts, some of which are known to be in progress at 145 the time of this writing, with many more expected to be defined in 146 time. 148 The normative dependency relationship between the various RFCs in the 149 collection is presented in the below diagram. The labels in the 150 diagram represent the primary purpose provided by each RFC. 151 Hyperlinks to each RFC are provided below the diagram. 153 crypto-types 154 ^ ^ 155 / \ 156 / \ 157 truststore keystore 158 ^ ^ ^ ^ 159 | +---------+ | | 160 | | | | 161 | +------------+ | 162 tcp-client-server | / | | 163 ^ ^ ssh-client-server | | 164 | | ^ tls-client-server 165 | | | ^ ^ http-client-server 166 | | | | | ^ 167 | | | +-----+ +---------+ | 168 | | | | | | 169 | +-----------|--------|--------------+ | | 170 | | | | | | 171 +-----------+ | | | | | 172 | | | | | | 173 | | | | | | 174 netconf-client-server restconf-client-server 176 +=======================+===========================================+ 177 |Label in Diagram | Originating RFC | 178 +=======================+===========================================+ 179 |crypto-types | [I-D.ietf-netconf-crypto-types] | 180 +-----------------------+-------------------------------------------+ 181 |truststore | [I-D.ietf-netconf-trust-anchors] | 182 +-----------------------+-------------------------------------------+ 183 |keystore | [I-D.ietf-netconf-keystore] | 184 +-----------------------+-------------------------------------------+ 185 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 186 +-----------------------+-------------------------------------------+ 187 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 188 +-----------------------+-------------------------------------------+ 189 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 190 +-----------------------+-------------------------------------------+ 191 |http-client-server | [I-D.ietf-netconf-http-client-server] | 192 +-----------------------+-------------------------------------------+ 193 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 194 +-----------------------+-------------------------------------------+ 195 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 196 +-----------------------+-------------------------------------------+ 198 Table 1: Label to RFC Mapping 200 1.2. Specification Language 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 204 "OPTIONAL" in this document are to be interpreted as described in BCP 205 14 [RFC2119] [RFC8174] when, and only when, they appear in all 206 capitals, as shown here. 208 1.3. Adherence to the NMDA 210 This document is compliant with the Network Management Datastore 211 Architecture (NMDA) [RFC8342]. For instance, trust anchors installed 212 during manufacturing (e.g., for trusted well-known services), are 213 expected to appear in (see Section 3). 215 1.4. Conventions 217 Various examples used in this document use a placeholder value for 218 binary data that has been base64 encoded (e.g., "BASE64VALUE="). 219 This placeholder value is used as real base64 encoded structures are 220 often many lines long and hence distracting to the example being 221 presented. 223 2. The "ietf-truststore" Module 225 This section defines a YANG 1.1 [RFC7950] module that defines a 226 "truststore" and groupings supporting downstream modules to reference 227 the truststore or have locally-defined definitions. 229 This section defines a YANG 1.1 [RFC7950] module called "ietf- 230 truststore". A high-level overview of the module is provided in 231 Section 2.1. Examples illustrating the module's use are provided in 232 Examples (Section 2.2). The YANG module itself is defined in 233 Section 2.3. 235 2.1. Data Model Overview 237 This section provides an overview of the "ietf-truststore" module in 238 terms of its features, typedefs, groupings, and protocol-accessible 239 nodes. 241 2.1.1. Features 243 The following diagram lists all the "feature" statements defined in 244 the "ietf-truststore" module: 246 Features: 247 +-- central-truststore-supported 248 +-- local-definitions-supported 249 +-- certificates 250 +-- public-keys 252 | The diagram above uses syntax that is similar to but not 253 | defined in [RFC8340]. 255 2.1.2. Typedefs 257 The following diagram lists the "typedef" statements defined in the 258 "ietf-truststore" module: 260 Typedefs: 261 leafref 262 +-- certificate-bag-ref 263 +-- certificate-ref 264 +-- public-key-bag-ref 265 +-- public-key-ref 267 | The diagram above uses syntax that is similar to but not 268 | defined in [RFC8340]. 270 Comments: 272 * All the typedefs defined in the "ietf-truststore" module extend 273 the base "leafref" type defined in [RFC7950]. 275 * The leafrefs refer to certificates, public keys, and bags in the 276 central truststore, when this module is implemented. 278 * These typedefs are provided as an aid to downstream modules that 279 import the "ietf-truststore" module. 281 2.1.3. Groupings 283 The "ietf-truststore" module defines the following "grouping" 284 statements: 286 * local-or-truststore-certs-grouping 287 * local-or-truststore-public-keys-grouping 288 * truststore-grouping 290 Each of these groupings are presented in the following subsections. 292 2.1.3.1. The "local-or-truststore-certs-grouping" Grouping 294 The following tree diagram [RFC8340] illustrates the "local-or- 295 truststore-certs-grouping" grouping: 297 grouping local-or-truststore-certs-grouping 298 +-- (local-or-truststore) 299 +--:(local) {local-definitions-supported}? 300 | +-- local-definition 301 | +-- certificate* [name] 302 | +-- name? string 303 | +---u ct:trust-anchor-cert-grouping 304 +--:(truststore) {central-truststore-supported,certificates}? 305 +-- truststore-reference? ts:certificate-bag-ref 307 Comments: 309 * The "local-or-truststore-certs-grouping" grouping is provided 310 soley as convenience to downstream modules that wish to offer an 311 option whether a bag of certificates can be defined locally or as 312 a reference to a bag in the truststore. 314 * A "choice" statement is used to expose the various options. Each 315 option is enabled by a "feature" statement. Additional "case" 316 statements MAY be augmented in if, e.g., there is a need to 317 reference a bag in an alternate location. 319 * For the "local-definition" option, the "certificate" node uses the 320 "trust-anchor-cert-grouping" grouping discussed in Section 2.1.4.7 321 of [I-D.ietf-netconf-crypto-types]. 323 * For the "truststore" option, the "truststore-reference" is an 324 instance of the "certificate-bag-ref" discussed in Section 2.1.2. 326 2.1.3.2. The "local-or-truststore-public-keys-grouping" Grouping 328 The following tree diagram [RFC8340] illustrates the "local-or- 329 truststore-public-keys-grouping" grouping: 331 grouping local-or-truststore-public-keys-grouping 332 +-- (local-or-truststore) 333 +--:(local) {local-definitions-supported}? 334 | +-- local-definition 335 | +-- public-key* [name] 336 | +-- name? string 337 | +---u ct:public-key-grouping 338 +--:(truststore) {central-truststore-supported,public-keys}? 339 +-- truststore-reference? ts:public-key-bag-ref 341 Comments: 343 * The "local-or-truststore-public-keys-grouping" grouping is 344 provided soley as convenience to downstream modules that wish to 345 offer an option whether a bag of public keys can be defined 346 locally or as a reference to a bag in the truststore. 348 * A "choice" statement is used to expose the various options. Each 349 option is enabled by a "feature" statement. Additional "case" 350 statements MAY be augmented in if, e.g., there is a need to 351 reference a bag in an alternate location. 353 * For the "local-definition" option, the "public-key" node uses the 354 "public-key-grouping" grouping discussed in Section 2.1.4.4 of 355 [I-D.ietf-netconf-crypto-types]. 357 * For the "truststore" option, the "truststore-reference" is an 358 instance of the "certificate-bag-ref" discussed in Section 2.1.2. 360 2.1.3.3. The "truststore-grouping" Grouping 362 The following tree diagram [RFC8340] illustrates the "truststore- 363 grouping" grouping: 365 grouping truststore-grouping 366 +-- certificate-bags {certificates}? 367 | +-- certificate-bag* [name] 368 | +-- name? string 369 | +-- description? string 370 | +-- certificate* [name] 371 | +-- name? string 372 | +---u ct:trust-anchor-cert-grouping 373 +-- public-key-bags {public-keys}? 374 +-- public-key-bag* [name] 375 +-- name? string 376 +-- description? string 377 +-- public-key* [name] 378 +-- name? string 379 +---u ct:public-key-grouping 381 Comments: 383 * The "truststore-grouping" grouping defines a truststore instance 384 as being composed of certificates and/or public keys, both of 385 which are enabled by "feature" statements. The structure 386 supporting certificates and public keys is essentially the same, 387 having an outer list of "bags" containing in inner list of objects 388 (certificates or public keys). The bags enable trust anchors 389 serving a common purpose to be grouped and referenced together. 391 * For certificates, each certificate is defined by the "trust- 392 anchor-cert-grouping" grouping Section 2.1.4.7 of 393 [I-D.ietf-netconf-crypto-types]. Thus the "cert-data" node is a 394 CMS structure that can be composed of a chain of one or more 395 certificates. Additionally, the "certificate-expiration" 396 notification enables the server to alert clients when certificates 397 are nearing or have already expired. 399 * For public keys, each public key is defined by the "public-key- 400 grouping" grouping Section 2.1.4.4 of 401 [I-D.ietf-netconf-crypto-types]. Thus the "public-key" node can 402 be one of any number of structures specified by the "public-key- 403 format" identity node. 405 2.1.4. Protocol-accessible Nodes 407 The following tree diagram [RFC8340] lists all the protocol- 408 accessible nodes defined in the "ietf-truststore" module, without 409 expanding the "grouping" statements: 411 module: ietf-truststore 412 +--rw truststore 413 +---u truststore-grouping 415 grouping local-or-truststore-certs-grouping 416 +-- (local-or-truststore) 417 +--:(local) {local-definitions-supported}? 418 | +-- local-definition 419 | +-- certificate* [name] 420 | +-- name? string 421 | +---u ct:trust-anchor-cert-grouping 422 +--:(truststore) {central-truststore-supported,certificates}? 423 +-- truststore-reference? ts:certificate-bag-ref 424 grouping local-or-truststore-public-keys-grouping 425 +-- (local-or-truststore) 426 +--:(local) {local-definitions-supported}? 427 | +-- local-definition 428 | +-- public-key* [name] 429 | +-- name? string 430 | +---u ct:public-key-grouping 431 +--:(truststore) {central-truststore-supported,public-keys}? 432 +-- truststore-reference? ts:public-key-bag-ref 433 grouping truststore-grouping 434 +-- certificate-bags {certificates}? 435 | +-- certificate-bag* [name] 436 | +-- name? string 437 | +-- description? string 438 | +-- certificate* [name] 439 | +-- name? string 440 | +---u ct:trust-anchor-cert-grouping 441 +-- public-key-bags {public-keys}? 442 +-- public-key-bag* [name] 443 +-- name? string 444 +-- description? string 445 +-- public-key* [name] 446 +-- name? string 447 +---u ct:public-key-grouping 449 The following tree diagram [RFC8340] lists all the protocol- 450 accessible nodes defined in the "ietf-truststore" module, with all 451 "grouping" statements expanded, enabling the truststore's full 452 structure to be seen: 454 module: ietf-truststore 455 +--rw truststore 456 +--rw certificate-bags {certificates}? 457 | +--rw certificate-bag* [name] 458 | +--rw name string 459 | +--rw description? string 460 | +--rw certificate* [name] 461 | +--rw name string 462 | +--rw cert-data trust-anchor-cert-cms 463 | +---n certificate-expiration 464 | {certificate-expiration-notification}? 465 | +-- expiration-date yang:date-and-time 466 +--rw public-key-bags {public-keys}? 467 +--rw public-key-bag* [name] 468 +--rw name string 469 +--rw description? string 470 +--rw public-key* [name] 471 +--rw name string 472 +--rw public-key-format identityref 473 +--rw public-key binary 475 grouping local-or-truststore-certs-grouping 476 +-- (local-or-truststore) 477 +--:(local) {local-definitions-supported}? 478 | +-- local-definition 479 | +-- certificate* [name] 480 | +-- name? string 481 | +-- cert-data trust-anchor-cert-cms 482 | +---n certificate-expiration 483 | {certificate-expiration-notification}? 484 | +-- expiration-date yang:date-and-time 485 +--:(truststore) {central-truststore-supported,certificates}? 486 +-- truststore-reference? ts:certificate-bag-ref 487 grouping local-or-truststore-public-keys-grouping 488 +-- (local-or-truststore) 489 +--:(local) {local-definitions-supported}? 490 | +-- local-definition 491 | +-- public-key* [name] 492 | +-- name? string 493 | +-- public-key-format identityref 494 | +-- public-key binary 495 +--:(truststore) {central-truststore-supported,public-keys}? 496 +-- truststore-reference? ts:public-key-bag-ref 497 grouping truststore-grouping 498 +-- certificate-bags {certificates}? 499 | +-- certificate-bag* [name] 500 | +-- name? string 501 | +-- description? string 502 | +-- certificate* [name] 503 | +-- name? string 504 | +-- cert-data trust-anchor-cert-cms 505 | +---n certificate-expiration 506 | {certificate-expiration-notification}? 507 | +-- expiration-date yang:date-and-time 508 +-- public-key-bags {public-keys}? 509 +-- public-key-bag* [name] 510 +-- name? string 511 +-- description? string 512 +-- public-key* [name] 513 +-- name? string 514 +-- public-key-format identityref 515 +-- public-key binary 517 Comments: 519 * Protocol-accessible nodes are those nodes that are accessible when 520 the module is "implemented", as described in Section 5.6.5 of 521 [RFC7950]. 523 * The protcol-accessible nodes for the "ietf-truststore" module are 524 an instance of the "truststore-grouping" grouping discussed in 525 Section 2.1.3.3. 527 * The reason for why the "truststore-grouping" exists separate from 528 the protocol-accessible nodes definition is to enable instances of 529 the truststore to be instantiated in other locations, as may be 530 needed or desired by some modules. 532 2.2. Example Usage 534 The examples in this section are encoded using XML, such as might be 535 the case when using the NETCONF protocol. Other encodings MAY be 536 used, such as JSON when using the RESTCONF protocol. 538 2.2.1. A Truststore Instance 540 This section presents an example illustrating trust anchors in 541 , as per Section 2.1.4. Please see Section 3 for an 542 example illustrating built-in values in . 544 The example contained in this section defines eight bags of trust 545 anchors. There are four certificate-based bags and four public key 546 based bags. The following diagram provides an overview of the 547 contents in the example: 549 Certificate Bags 550 +-- Trust anchor certs for authenticating a set of remote servers 551 +-- End entity certs for authenticating a set of remote servers 552 +-- Trust anchor certs for authenticating a set of remote clients 553 +-- End entity certs for authenticating a set of remote clients 555 Public Key Bags 556 +-- SSH keys to authenticate a set of remote SSH server 557 +-- SSH keys to authenticate a set of remote SSH clients 558 +-- Raw public keys to authenticate a set of remote SSH server 559 +-- Raw public keys to authenticate a set of remote SSH clients 561 Following is the full example: 563 567 568 570 571 572 trusted-server-ca-certs 573 574 Trust anchors (i.e. CA certs) used to authenticate server 575 certificates. A server certificate is authenticated if its 576 end-entity certificate has a chain of trust to one of these 577 certificates. 578 579 580 Server Cert Issuer #1 581 BASE64VALUE= 582 583 584 Server Cert Issuer #2 585 BASE64VALUE= 586 587 589 590 591 trusted-server-ee-certs 592 593 Specific end-entity certificates used to authenticate server 594 certificates. A server certificate is authenticated if its 595 end-entity certificate is an exact match to one of these 596 certificates. 598 599 600 My Application #1 601 BASE64VALUE= 602 603 604 My Application #2 605 BASE64VALUE= 606 607 609 610 611 trusted-client-ca-certs 612 613 Trust anchors (i.e. CA certs) used to authenticate client 614 certificates. A client certificate is authenticated if its 615 end-entity certificate has a chain of trust to one of these 616 certificates. 617 618 619 Client Identity Issuer #1 620 BASE64VALUE= 621 622 623 Client Identity Issuer #2 624 BASE64VALUE= 625 626 628 629 630 trusted-client-ee-certs 631 632 Specific end-entity certificates used to authenticate client 633 certificates. A client certificate is authenticated if its 634 end-entity certificate is an exact match to one of these 635 certificates. 636 637 638 George Jetson 639 BASE64VALUE= 640 641 642 Fred Flintstone 643 BASE64VALUE= 644 645 647 649 650 652 653 654 trusted-ssh-public-keys 655 656 Specific SSH public keys used to authenticate SSH server 657 public keys. An SSH server public key is authenticated if 658 its public key is an exact match to one of these public keys. 660 This list of SSH public keys is analogous to OpenSSH's 661 "/etc/ssh/ssh_known_hosts" file. 662 663 664 corp-fw1 665 666 ct:ssh-public-key-format 667 668 BASE64VALUE= 669 670 671 corp-fw2 672 673 ct:ssh-public-key-format 674 675 BASE64VALUE= 676 677 679 680 681 SSH Public Keys for Application A 682 683 SSH public keys used to authenticate application A's SSH 684 public keys. An SSH public key is authenticated if it 685 is an exact match to one of these public keys. 686 687 688 Application Instance #1 689 690 ct:ssh-public-key-format 691 692 BASE64VALUE= 693 694 695 Application Instance #2 696 697 ct:ssh-public-key-format 698 699 BASE64VALUE= 700 701 703 704 705 Raw Public Keys for TLS Servers 706 707 Raw Public Key #1 708 709 ct:subject-public-key-info-format 710 BASE64VALUE= 711 712 713 Raw Public Key #2 714 715 ct:subject-public-key-info-format 716 717 BASE64VALUE= 718 719 721 722 723 Raw Public Keys for TLS Clients 724 725 Raw Public Key #1 726 727 ct:subject-public-key-info-format 728 729 BASE64VALUE= 730 731 732 Raw Public Key #2 733 734 ct:subject-public-key-info-format 735 736 BASE64VALUE= 737 738 739 740 742 2.2.2. A Certificate Expiration Notification 744 The following example illustrates the "certificate-expiration" 745 notification (per Section 2.1.4.6 of [I-D.ietf-netconf-crypto-types]) 746 for a certificate configured in the truststore in Section 2.2.1. 748 =============== NOTE: '\' line wrapping per RFC 8792 ================ 750 752 2018-05-25T00:01:00Z 753 754 755 756 trusted-client-ee-certs 757 758 George Jetson 759 760 2018-08-05T14:18:53-05:00 762 763 764 765 766 767 769 2.2.3. The "Local or Truststore" Groupings 771 This section illustrates the various "local-or-truststore" groupings 772 defined in the "ietf-truststore" module, specifically the "local-or- 773 truststore-certs-grouping" (Section 2.1.3.1) and "local-or- 774 truststore-public-keys-grouping" (Section 2.1.3.2) groupings. 776 These examples assume the existence of an example module called "ex- 777 truststore-usage" having the namespace "http://example.com/ns/ 778 example-truststore-usage". 780 The ex-truststore-usage module is first presented using tree diagrams 781 [RFC8340], followed by an instance example illustrating all the 782 "local-or-truststore" groupings in use, followed by the YANG module 783 itself. 785 The following tree diagram illustrates "ex-truststore-usage" without 786 expanding the "grouping" statements: 788 module: ex-truststore-usage 789 +--rw truststore-usage 790 +--rw cert* [name] 791 | +--rw name string 792 | +---u ts:local-or-truststore-certs-grouping 793 +--rw public-key* [name] 794 +--rw name string 795 +---u ts:local-or-truststore-public-keys-grouping 797 The following tree diagram illustrates the "ex-truststore-usage" 798 module, with all "grouping" statements expanded, enabling the 799 truststore's full structure to be seen: 801 module: ex-truststore-usage 802 +--rw truststore-usage 803 +--rw cert* [name] 804 | +--rw name string 805 | +--rw (local-or-truststore) 806 | +--:(local) {local-definitions-supported}? 807 | | +--rw local-definition 808 | | +--rw certificate* [name] 809 | | +--rw name string 810 | | +--rw cert-data 811 | | | trust-anchor-cert-cms 812 | | +---n certificate-expiration 813 | | {certificate-expiration-notification}? 814 | | +-- expiration-date yang:date-and-time 815 | +--:(truststore) 816 | {central-truststore-supported,certificates}? 817 | +--rw truststore-reference? ts:certificate-bag-ref 818 +--rw public-key* [name] 819 +--rw name string 820 +--rw (local-or-truststore) 821 +--:(local) {local-definitions-supported}? 822 | +--rw local-definition 823 | +--rw public-key* [name] 824 | +--rw name string 825 | +--rw public-key-format identityref 826 | +--rw public-key binary 827 +--:(truststore) 828 {central-truststore-supported,public-keys}? 829 +--rw truststore-reference? ts:public-key-bag-ref 831 The following example provides two equivalent instances of each 832 grouping, the first being a reference to a truststore and the second 833 being locally-defined. The instance having a reference to a 834 truststore is consistent with the truststore defined in 835 Section 2.2.1. The two instances are equivalent, as the locally- 836 defined instance example contains the same values defined by the 837 truststore instance referenced by its sibling example. 839 =============== NOTE: '\' line wrapping per RFC 8792 ================ 841 845 846 848 849 example 1a 850 trusted-client-ca-certs 852 854 855 example 1b 856 857 my-trusted-client-ca-certs 858 859 Client Identity Issuer #1 860 BASE64VALUE= 861 862 863 Client Identity Issuer #2 864 BASE64VALUE= 865 866 867 869 870 872 873 example 2a 874 trusted-ssh-public-keys 876 877 878 example 2b 879 880 trusted-ssh-public-keys 881 882 corp-fw1 883 884 ct:ssh-public-key-format 885 886 BASE64VALUE= 887 888 889 corp-fw2 890 891 ct:ssh-public-key-format 892 893 BASE64VALUE= 894 895 896 898 900 Following is the "ex-truststore-usage" module's YANG definition: 902 module ex-truststore-usage { 903 yang-version 1.1; 904 namespace "http://example.com/ns/example-truststore-usage"; 905 prefix etu; 907 import ietf-truststore { 908 prefix ts; 909 reference 910 "RFC BBBB: A YANG Data Model for a Truststore"; 911 } 913 organization 914 "Example Corporation"; 916 contact 917 "Author: YANG Designer "; 919 description 920 "This module illustrates notable groupings defined in 921 the 'ietf-truststore' module."; 923 revision 2022-03-07 { 924 description 925 "Initial version"; 926 reference 927 "RFC BBBB: A YANG Data Model for a Truststore"; 928 } 930 container truststore-usage { 931 description 932 "An illustration of the various truststore groupings."; 933 list cert { 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-certs-grouping; 941 description 942 "An cert that may be configured locally or be 943 a reference to a cert in the truststore."; 944 } 945 list public-key { 946 key "name"; 947 leaf name { 948 type string; 949 description 950 "An arbitrary name for this cert."; 951 } 952 uses ts:local-or-truststore-public-keys-grouping; 953 description 954 "An public key that may be configured locally or be 955 a reference to a public key in the truststore."; 956 } 957 } 958 } 960 2.3. YANG Module 962 This YANG module imports modules from [RFC8341] and 963 [I-D.ietf-netconf-crypto-types]. 965 file "ietf-truststore@2022-03-07.yang" 967 module ietf-truststore { 968 yang-version 1.1; 969 namespace "urn:ietf:params:xml:ns:yang:ietf-truststore"; 970 prefix ts; 972 import ietf-netconf-acm { 973 prefix nacm; 974 reference 975 "RFC 8341: Network Configuration Access Control Model"; 976 } 978 import ietf-crypto-types { 979 prefix ct; 980 reference 981 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 982 } 984 organization 985 "IETF NETCONF (Network Configuration) Working Group"; 987 contact 988 "WG Web : https://datatracker.ietf.org/wg/netconf 989 WG List : NETCONF WG list 990 Author : Kent Watsen "; 992 description 993 "This module defines a 'truststore' to centralize management 994 of trust anchors including certificates and public keys. 996 Copyright (c) 2021 IETF Trust and the persons identified 997 as authors of the code. All rights reserved. 999 Redistribution and use in source and binary forms, with 1000 or without modification, is permitted pursuant to, and 1001 subject to the license terms contained in, the Revised 1002 BSD License set forth in Section 4.c of the IETF Trust's 1003 Legal Provisions Relating to IETF Documents 1004 (https://trustee.ietf.org/license-info). 1006 This version of this YANG module is part of RFC BBBB 1007 (https://www.rfc-editor.org/info/rfcBBBB); see the RFC 1008 itself for full legal notices. 1010 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1011 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1012 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1013 are to be interpreted as described in BCP 14 (RFC 2119) 1014 (RFC 8174) when, and only when, they appear in all 1015 capitals, as shown here."; 1017 revision 2022-03-07 { 1018 description 1019 "Initial version"; 1020 reference 1021 "RFC BBBB: A YANG Data Model for a Truststore"; 1022 } 1024 /****************/ 1025 /* Features */ 1026 /****************/ 1028 feature central-truststore-supported { 1029 description 1030 "The 'central-truststore-supported' feature indicates that 1031 the server supports the truststore (i.e., implements the 1032 'ietf-truststore' module)."; 1033 } 1035 feature local-definitions-supported { 1036 description 1037 "The 'local-definitions-supported' feature indicates that 1038 the server supports locally-defined trust anchors."; 1039 } 1041 feature certificates { 1042 description 1043 "The 'certificates' feature indicates that the server 1044 implements the /truststore/certificate-bags subtree."; 1045 } 1047 feature public-keys { 1048 description 1049 "The 'public-keys' feature indicates that the server 1050 implements the /truststore/public-key-bags subtree."; 1051 } 1053 /****************/ 1054 /* Typedefs */ 1055 /****************/ 1057 typedef certificate-bag-ref { 1058 type leafref { 1059 path "/ts:truststore/ts:certificate-bags/" 1060 + "ts:certificate-bag/ts:name"; 1061 } 1062 description 1063 "This typedef defines a reference to a certificate bag 1064 in the truststore, when this module is implemented."; 1065 } 1067 typedef certificate-ref { 1068 type leafref { 1069 path "/ts:truststore/ts:certificate-bags/ts:certificate-bag" 1070 + "[ts:name = current()/../ts:certificate-bag]/" 1071 + "ts:certificate/ts:name"; 1072 } 1073 description 1074 "This typedef defines a reference to a specific certificate 1075 in a certificate bag in the truststore, when this module 1076 is implemented. This typedef requires that there exist a 1077 sibling 'leaf' node called 'certificate-bag' that SHOULD 1078 have the typedef 'certificate-bag-ref'."; 1079 } 1081 typedef public-key-bag-ref { 1082 type leafref { 1083 path "/ts:truststore/ts:public-key-bags/" 1084 + "ts:public-key-bag/ts:name"; 1085 } 1086 description 1087 "This typedef defines a reference to a public key bag 1088 in the truststore, when this module is implemented."; 1089 } 1091 typedef public-key-ref { 1092 type leafref { 1093 path "/ts:truststore/ts:public-key-bags/ts:public-key-bag" 1094 + "[ts:name = current()/../ts:public-key-bag]/" 1095 + "ts:public-key/ts:name"; 1096 } 1097 description 1098 "This typedef defines a reference to a specific public key 1099 in a public key bag in the truststore, when this module is 1100 implemented. This typedef requires that there exist a 1101 sibling 'leaf' node called 'public-key-bag' that SHOULD 1102 have the typedef 'public-key-bag-ref'."; 1103 } 1105 /*****************/ 1106 /* Groupings */ 1107 /*****************/ 1109 grouping local-or-truststore-certs-grouping { 1110 description 1111 "A grouping that allows the certificates to be either 1112 configured locally, within the using data model, or be a 1113 reference to a certificate bag stored in the truststore. 1115 Servers that do not 'implement' this module, and hence 1116 'central-truststore-supported' is not defined, SHOULD 1117 augment in custom 'case' statements enabling references 1118 to the alternate truststore locations."; 1119 choice local-or-truststore { 1120 nacm:default-deny-write; 1121 mandatory true; 1122 description 1123 "A choice between an inlined definition and a definition 1124 that exists in the truststore."; 1125 case local { 1126 if-feature "local-definitions-supported"; 1127 container local-definition { 1128 description 1129 "A container for locally configured trust anchor 1130 certificates."; 1131 list certificate { 1132 key "name"; 1133 min-elements 1; 1134 description 1135 "A trust anchor certificate."; 1136 leaf name { 1137 type string; 1138 description 1139 "An arbitrary name for this certificate."; 1140 } 1141 uses ct:trust-anchor-cert-grouping { 1142 refine "cert-data" { 1143 mandatory true; 1144 } 1145 } 1146 } 1147 } 1148 } 1149 case truststore { 1150 if-feature "central-truststore-supported"; 1151 if-feature "certificates"; 1152 leaf truststore-reference { 1153 type ts:certificate-bag-ref; 1154 description 1155 "A reference to a certificate bag that exists in the 1156 truststore, when this module is implemented."; 1157 } 1158 } 1159 } 1160 } 1162 grouping local-or-truststore-public-keys-grouping { 1163 description 1164 "A grouping that allows the public keys to be either 1165 configured locally, within the using data model, or be a 1166 reference to a public key bag stored in the truststore. 1168 Servers that do not 'implement' this module, and hence 1169 'central-truststore-supported' is not defined, SHOULD 1170 augment in custom 'case' statements enabling references 1171 to the alternate truststore locations."; 1172 choice local-or-truststore { 1173 nacm:default-deny-write; 1174 mandatory true; 1175 description 1176 "A choice between an inlined definition and a definition 1177 that exists in the truststore."; 1178 case local { 1179 if-feature "local-definitions-supported"; 1180 container local-definition { 1181 description 1182 "A container to hold local public key definitions."; 1183 list public-key { 1184 key "name"; 1185 description 1186 "A public key definition."; 1187 leaf name { 1188 type string; 1189 description 1190 "An arbitrary name for this public key."; 1191 } 1192 uses ct:public-key-grouping; 1193 } 1194 } 1195 } 1196 case truststore { 1197 if-feature "central-truststore-supported"; 1198 if-feature "public-keys"; 1199 leaf truststore-reference { 1200 type ts:public-key-bag-ref; 1201 description 1202 "A reference to a bag of public keys that exists 1203 in the truststore, when this module is implemented."; 1204 } 1205 } 1206 } 1207 } 1209 grouping truststore-grouping { 1210 description 1211 "A grouping definition that enables use in other contexts. 1212 Where used, implementations MUST augment new 'case' 1213 statements into the various local-or-truststore 'choice' 1214 statements to supply leafrefs to the model-specific 1215 location(s)."; 1216 container certificate-bags { 1217 nacm:default-deny-write; 1218 if-feature "certificates"; 1219 description 1220 "A collection of certificate bags."; 1221 list certificate-bag { 1222 key "name"; 1223 description 1224 "A bag of certificates. Each bag of certificates SHOULD 1225 be for a specific purpose. For instance, one bag could 1226 be used to authenticate a specific set of servers, while 1227 another could be used to authenticate a specific set of 1228 clients."; 1229 leaf name { 1230 type string; 1231 description 1232 "An arbitrary name for this bag of certificates."; 1233 } 1234 leaf description { 1235 type string; 1236 description 1237 "A description for this bag of certificates. The 1238 intended purpose for the bag SHOULD be described."; 1239 } 1240 list certificate { 1241 key "name"; 1242 description 1243 "A trust anchor certificate."; 1244 leaf name { 1245 type string; 1246 description 1247 "An arbitrary name for this certificate."; 1248 } 1249 uses ct:trust-anchor-cert-grouping { 1250 refine "cert-data" { 1251 mandatory true; 1252 } 1253 } 1254 } 1255 } 1256 } 1257 container public-key-bags { 1258 nacm:default-deny-write; 1259 if-feature "public-keys"; 1260 description 1261 "A collection of public key bags."; 1262 list public-key-bag { 1263 key "name"; 1264 description 1265 "A bag of public keys. Each bag of keys SHOULD be for 1266 a specific purpose. For instance, one bag could be used 1267 authenticate a specific set of servers, while another 1268 could be used to authenticate a specific set of clients."; 1269 leaf name { 1270 type string; 1271 description 1272 "An arbitrary name for this bag of public keys."; 1273 } 1274 leaf description { 1275 type string; 1276 description 1277 "A description for this bag public keys. The 1278 intended purpose for the bag SHOULD be described."; 1279 } 1280 list public-key { 1281 key "name"; 1282 description 1283 "A public key."; 1284 leaf name { 1285 type string; 1286 description 1287 "An arbitrary name for this public key."; 1288 } 1289 uses ct:public-key-grouping; 1290 } 1291 } 1292 } 1293 } 1295 /*********************************/ 1296 /* Protocol accessible nodes */ 1297 /*********************************/ 1299 container truststore { 1300 nacm:default-deny-write; 1301 description 1302 "The truststore contains bags of certificates and 1303 public keys."; 1304 uses truststore-grouping; 1305 } 1306 } 1308 1310 3. Support for Built-in Trust Anchors 1312 In some implementations, a server may define some built-in trust 1313 anchors. For instance, there may be built-in trust anchors enabling 1314 the server to securely connect to well-known services (e.g., an SZTP 1315 [RFC8572] bootstrap server) or public CA certificates to connect to 1316 arbitrary services using public PKI. 1318 Built-in trust anchors are expected to be set by a vendor-specific 1319 process. Any ability for operators to modify built-in trust anchors 1320 is outside the scope of this document. 1322 As built-in trust anchors are provided by the server, they are 1323 present in (and [I-D.ma-netmod-with-system], 1324 if used). The example below illustrates what the truststore in 1325 might look like for a server in its factory default 1326 state. 1328 1333 1335 1336 Built-In Manufacturer Trust Anchor Certificates 1337 1338 Certificates built into the device for authenticating 1339 manufacturer-signed objects, such as TLS server certificates, 1340 vouchers, etc. 1341 1342 1343 Manufacturer Root CA Cert 1344 BASE64VALUE= 1345 1346 1348 1349 Built-In Public Trust Anchor Certificates 1350 1351 Certificates built into the device for authenticating 1352 certificates issued by public certificate authorities, 1353 such as the end-entity certificate for web servers. 1354 1355 1356 Public Root CA Cert 1 1357 BASE64VALUE= 1358 1359 1360 Public Root CA Cert 2 1361 BASE64VALUE= 1362 1363 1364 Public Root CA Cert 3 1365 BASE64VALUE= 1366 1367 1369 1370 1372 In order for the built-in bags of trust anchors and/or their trust 1373 anchors to be referenced by configuration, they MUST first be copied 1374 into . 1376 The built-in bags and/or their trust anchors MUST be copied into 1377 using the same "key" values if it is desired for the server 1378 to maintain/update them (e.g., a software update may update a bag of 1379 trusted public CA certificates used for TLS-client connections). 1381 Built-in bags and/or their trust anchors MAY be copied into other 1382 parts of the configuration but, by doing so, they lose their 1383 association to the built-in entries and any assurances afforded by 1384 knowing they are/were built-in. 1386 The built-in bags and/or their trust anchors are immutable by 1387 configuration operations. Servers MUST ignore attempts to modify any 1388 aspect of built-in bags and/or their trust anchors from . 1390 The following example illustrates how a single built-in public CA 1391 certificate from the previous example has been propagated to 1392 : 1394 1397 1399 1400 Built-In Public Trust Anchor Certificates 1401 1402 Certificates built into the device for authenticating 1403 certificates issued by public certificate authorities, 1404 such as the end-entity certificate for web servers. 1406 Only the subset of the certificates that are referenced 1407 by other configuration nodes need to be copied. For 1408 instance, only "Public Root CA Cert 3" is present here. 1410 No new certificates can be added, nor existing certificate 1411 values changed. Missing certificates have no effect on 1412 "operational" when the configuration is applied. 1413 1414 1415 Public Root CA Cert 3 1416 BASE64VALUE= 1417 1418 1420 1421 1423 4. Security Considerations 1425 4.1. Security of Data at Rest 1427 The YANG module defined in this document defines a mechanism called a 1428 "truststore" that, by its name, suggests that its contents are 1429 protected from unauthorized modification. 1431 Security controls for the API (i.e., data in motion) are discussed in 1432 Section 4.3, but controls for the data at rest cannot be specified by 1433 the YANG module. 1435 In order to satisfy the expectations of a "truststore", it is 1436 RECOMMENDED that implementations ensure that the truststore contents 1437 are protected from unauthorized modifications when at rest. 1439 4.2. Unconstrained Public Key Usage 1441 This module enables the configuration of public keys without 1442 constraints on their usage, e.g., what operations the key is allowed 1443 to be used for (encryption, verification, both). 1445 This module also enables the configuration of certificates, where 1446 each certificate may constrain the usage of the public key according 1447 to local policy. 1449 4.3. The "ietf-truststore" YANG Module 1451 The YANG module defined in this document is designed to be accessed 1452 via YANG based management protocols, such as NETCONF [RFC6241] and 1453 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1454 implement secure transport layers (e.g., SSH, TLS) with mutual 1455 authentication. 1457 The NETCONF access control model (NACM) [RFC8341] provides the means 1458 to restrict access for particular users to a pre-configured subset of 1459 all available protocol operations and content. 1461 None of the readable data nodes defined in this YANG module are 1462 considered sensitive or vulnerable in network environments. The NACM 1463 "default-deny-all" extension has not been set for any data nodes 1464 defined in this module. 1466 All the writable data nodes defined by this module, both in the 1467 "grouping" statements as well as the protocol-accessible "truststore" 1468 instance, may be considered sensitive or vulnerable in some network 1469 environments. For instance, any modification to a trust anchor or 1470 reference to a trust anchor may dramatically alter the implemented 1471 security policy. For this reason, the NACM extension "default-deny- 1472 write" has been set for all data nodes defined in this module. 1474 This module does not define any "rpc" or "action" statements, and 1475 thus the security considerations for such is not provided here. 1477 5. IANA Considerations 1479 5.1. The "IETF XML" Registry 1481 This document registers one URI in the "ns" subregistry of the IETF 1482 XML Registry [RFC3688]. Following the format in [RFC3688], the 1483 following registration is requested: 1485 URI: urn:ietf:params:xml:ns:yang:ietf-truststore 1486 Registrant Contact: The IESG 1487 XML: N/A, the requested URI is an XML namespace. 1489 5.2. The "YANG Module Names" Registry 1491 This document registers one YANG module in the YANG Module Names 1492 registry [RFC6020]. Following the format in [RFC6020], the following 1493 registration is requested: 1495 name: ietf-truststore 1496 namespace: urn:ietf:params:xml:ns:yang:ietf-truststore 1497 prefix: ts 1498 reference: RFC BBBB 1500 6. References 1502 6.1. Normative References 1504 [I-D.ietf-netconf-crypto-types] 1505 Watsen, K., "YANG Data Types and Groupings for 1506 Cryptography", Work in Progress, Internet-Draft, draft- 1507 ietf-netconf-crypto-types-21, 14 September 2021, 1508 . 1511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1512 Requirement Levels", BCP 14, RFC 2119, 1513 DOI 10.17487/RFC2119, March 1997, 1514 . 1516 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1517 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1518 . 1520 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1521 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1522 May 2017, . 1524 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1525 Access Control Model", STD 91, RFC 8341, 1526 DOI 10.17487/RFC8341, March 2018, 1527 . 1529 6.2. Informative References 1531 [I-D.ietf-netconf-http-client-server] 1532 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 1533 Servers", Work in Progress, Internet-Draft, draft-ietf- 1534 netconf-http-client-server-08, 14 December 2021, 1535 . 1538 [I-D.ietf-netconf-keystore] 1539 Watsen, K., "A YANG Data Model for a Keystore", Work in 1540 Progress, Internet-Draft, draft-ietf-netconf-keystore-23, 1541 14 December 2021, . 1544 [I-D.ietf-netconf-netconf-client-server] 1545 Watsen, K., "NETCONF Client and Server Models", Work in 1546 Progress, Internet-Draft, draft-ietf-netconf-netconf- 1547 client-server-24, 14 December 2021, 1548 . 1551 [I-D.ietf-netconf-restconf-client-server] 1552 Watsen, K., "RESTCONF Client and Server Models", Work in 1553 Progress, Internet-Draft, draft-ietf-netconf-restconf- 1554 client-server-24, 14 December 2021, 1555 . 1558 [I-D.ietf-netconf-ssh-client-server] 1559 Watsen, K., "YANG Groupings for SSH Clients and SSH 1560 Servers", Work in Progress, Internet-Draft, draft-ietf- 1561 netconf-ssh-client-server-26, 14 December 2021, 1562 . 1565 [I-D.ietf-netconf-tcp-client-server] 1566 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 1567 and TCP Servers", Work in Progress, Internet-Draft, draft- 1568 ietf-netconf-tcp-client-server-11, 14 December 2021, 1569 . 1572 [I-D.ietf-netconf-tls-client-server] 1573 Watsen, K., "YANG Groupings for TLS Clients and TLS 1574 Servers", Work in Progress, Internet-Draft, draft-ietf- 1575 netconf-tls-client-server-26, 14 December 2021, 1576 . 1579 [I-D.ietf-netconf-trust-anchors] 1580 Watsen, K., "A YANG Data Model for a Truststore", Work in 1581 Progress, Internet-Draft, draft-ietf-netconf-trust- 1582 anchors-16, 14 December 2021, 1583 . 1586 [I-D.ma-netmod-with-system] 1587 Ma, Q., Watsen, K., Wu, Q., Chong, F., and J. Lindblad, 1588 "System-defined Configuration", Work in Progress, 1589 Internet-Draft, draft-ma-netmod-with-system-02, 14 1590 February 2022, . 1593 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1594 DOI 10.17487/RFC3688, January 2004, 1595 . 1597 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1598 the Network Configuration Protocol (NETCONF)", RFC 6020, 1599 DOI 10.17487/RFC6020, October 2010, 1600 . 1602 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1603 and A. Bierman, Ed., "Network Configuration Protocol 1604 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1605 . 1607 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1608 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1609 . 1611 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1612 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1613 . 1615 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1616 and R. Wilton, "Network Management Datastore Architecture 1617 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1618 . 1620 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1621 Touch Provisioning (SZTP)", RFC 8572, 1622 DOI 10.17487/RFC8572, April 2019, 1623 . 1625 Appendix A. Change Log 1627 This section is to be removed before publishing as an RFC. 1629 A.1. 00 to 01 1631 * Added features "x509-certificates" and "ssh-host-keys". 1633 * Added nacm:default-deny-write to "trust-anchors" container. 1635 A.2. 01 to 02 1637 * Switched "list pinned-certificate" to use the "trust-anchor-cert- 1638 grouping" from crypto-types. Effectively the same definition as 1639 before. 1641 A.3. 02 to 03 1643 * Updated copyright date, boilerplate template, affiliation, folding 1644 algorithm, and reformatted the YANG module. 1646 A.4. 03 to 04 1648 * Added groupings 'local-or-truststore-certs-grouping' and 'local- 1649 or-truststore-host-keys-grouping', matching similar definitions in 1650 the keystore draft. Note new (and incomplete) "truststore" usage! 1652 * Related to above, also added features 'truststore-supported' and 1653 'local-trust-anchors-supported'. 1655 A.5. 04 to 05 1657 * Renamed "trust-anchors" to "truststore" 1659 * Removed "pinned." prefix everywhere, to match truststore rename 1661 * Moved everything under a top-level 'grouping' to enable use in 1662 other contexts. 1664 * Renamed feature from 'local-trust-anchors-supported' to 'local- 1665 definitions-supported' (same name used in keystore) 1667 * Removed the "require-instance false" statement from the "*-ref" 1668 typedefs. 1670 * Added missing "ssh-host-keys" and "x509-certificates" if-feature 1671 statements 1673 A.6. 05 to 06 1675 * Editorial changes only. 1677 A.7. 06 to 07 1679 * Added Henk Birkholz as a co-author (thanks Henk!) 1681 * Added PSKs and raw public keys to truststore. 1683 A.8. 07 to 08 1685 * Added new "Support for Built-in Trust Anchors" section. 1687 * Removed spurious "uses ct:trust-anchor-certs-grouping" line. 1689 * Removed PSK from model. 1691 A.9. 08 to 09 1693 * Removed remaining PSK references from text. 1695 * Wrapped each top-level list with a container. 1697 * Introduced "bag" term. 1699 * Merged "SSH Public Keys" and "Raw Public Keys" in a single "Public 1700 Keys" bag. Consuming downstream modules (i.e., "ietf-[ssh/tls]- 1701 [client/server]) refine the "public-key-format" to be either SSH 1702 or TLS specific as needed. 1704 A.10. 09 to 10 1706 * Removed "algorithm" node from examples. 1708 * Removed the no longer used statements supporting the old "ssh- 1709 public-key" and "raw-public-key" nodes. 1711 * Added a "Note to Reviewers" note to first page. 1713 A.11. 10 to 11 1715 * Corrected module prefix registered in the IANA Considerations 1716 section. 1718 * Modified 'local-or-truststore-certs-grouping' to use a list (not a 1719 leaf-list). 1721 * Added new example section "The Local or Truststore Groupings". 1723 * Clarified expected behavior for "built-in" certificates in 1724 1726 * Expanded "Data Model Overview section(s) [remove "wall" of tree 1727 diagrams]. 1729 * Updated the Security Considerations section. 1731 A.12. 11 to 12 1733 * Fixed a copy/paste issue in the "Data at Rest" Security 1734 Considerations section. 1736 A.13. 12 to 13 1738 * Fixed issues found by the SecDir review of the "keystore" draft. 1740 A.14. 13 to 14 1742 * Added an "Unconstrained Public Key Usage" Security Consideration 1743 to address concern raised by SecDir. 1745 * Addressed comments raised by YANG Doctor. 1747 A.15. 14 to 15 1749 * Added prefixes to 'path' statements per trust-anchors/issues/1 1750 * Renamed feature "truststore-supported" to "central-truststore- 1751 supported". 1753 * Associated with above, generally moved text to refer to a 1754 "central" truststore. 1756 * Removed two unecessary/unwanted "min-elements 1" and associated 1757 "presence" statements. 1759 * Aligned modules with `pyang -f` formatting. 1761 * Fixed nits found by YANG Doctor reviews. 1763 A.16. 15 to 16 1765 * Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples. 1767 * Minor editorial nits 1769 A.17. 16 to 17 1771 * fixup the 'WG Web' and 'WG List' lines in YANG module(s) 1773 * fixup copyright (i.e., s/Simplified/Revised/) in YANG module(s) 1775 * Added Informative reference to ma-netmod-with-system 1777 Acknowledgements 1779 The authors especially thank Henk Birkholz for contributing YANG to 1780 the ietf-truststore module supporting raw public keys and PSKs (pre- 1781 shared or pairwise-symmetric keys). While these contributions were 1782 eventually replaced by reusing the existing support for asymmetric 1783 and symmetric trust anchors, respectively, it was only thru Henk's 1784 initiative that the WG was able to come to that result. 1786 The authors additionally thank the following for helping give shape 1787 to this work (ordered by first name): Balazs Kovacs, Eric Voit, 1788 Juergen Schoenwaelder, Liang Xia, Martin Bjoerklund, Nick Hancock, 1789 and Yoav Nir. 1791 Author's Address 1793 Kent Watsen 1794 Watsen Networks 1795 Email: kent+ietf@watsen.net