idnits 2.17.00 (12 Aug 2021) /tmp/idnits12143/draft-ietf-netconf-trust-anchors-16.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 464 has weird spacing: '...on-date yan...' == Line 471 has weird spacing: '...-format ide...' == Line 483 has weird spacing: '...on-date yan...' == Line 492 has weird spacing: '...-format ide...' == Line 506 has weird spacing: '...on-date yan...' == (3 more instances...) -- The document date (14 December 2021) is 157 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 (-22) exists of draft-ietf-netconf-crypto-types-21 == Outdated reference: A later version (-09) exists of draft-ietf-netconf-http-client-server-07 == Outdated reference: A later version (-24) exists of draft-ietf-netconf-keystore-22 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-netconf-client-server-23 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-restconf-client-server-23 == Outdated reference: A later version (-27) exists of draft-ietf-netconf-ssh-client-server-25 == Outdated reference: A later version (-12) exists of draft-ietf-netconf-tcp-client-server-10 == Outdated reference: A later version (-27) exists of draft-ietf-netconf-tls-client-server-25 == Outdated reference: A later version (-17) exists of draft-ietf-netconf-trust-anchors-15 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 14 December 2021 5 Expires: 17 June 2022 7 A YANG Data Model for a Truststore 8 draft-ietf-netconf-trust-anchors-16 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-12-14 --> 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 17 June 2022. 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 36 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 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 115 1. Introduction 117 This document defines a YANG 1.1 [RFC7950] module having the 118 following characteristics: 120 Provide a central truststore for storing raw public keys and/or 121 certificates. 123 Provide support for storing named bags of raw public keys and/or 124 named bags of certificates. 126 Provide types that can be used to reference raw public keys or 127 certificates stored in the central truststore. 129 Provide groupings that enable raw public keys and certificates to 130 be configured locally or as references truststore instances. 132 Enable the truststore to be instantiated in other data models, in 133 addition to or in lieu of the central trusttore instance. 135 1.1. Relation to other RFCs 137 This document presents one or more YANG modules [RFC7950] that are 138 part of a collection of RFCs that work together to, ultimately, 139 enable the configuration of the clients and servers of both the 140 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 142 The modules have been defined in a modular fashion to enable their 143 use by other efforts, some of which are known to be in progress at 144 the time of this writing, with many more expected to be defined in 145 time. 147 The normative dependency relationship between the various RFCs in the 148 collection is presented in the below diagram. The labels in the 149 diagram represent the primary purpose provided by each RFC. 150 Hyperlinks to each RFC are provided below the diagram. 152 crypto-types 153 ^ ^ 154 / \ 155 / \ 156 truststore keystore 157 ^ ^ ^ ^ 158 | +---------+ | | 159 | | | | 160 | +------------+ | 161 tcp-client-server | / | | 162 ^ ^ ssh-client-server | | 163 | | ^ tls-client-server 164 | | | ^ ^ http-client-server 165 | | | | | ^ 166 | | | +-----+ +---------+ | 167 | | | | | | 168 | +-----------|--------|--------------+ | | 169 | | | | | | 170 +-----------+ | | | | | 171 | | | | | | 172 | | | | | | 173 netconf-client-server restconf-client-server 175 +=======================+===========================================+ 176 |Label in Diagram | Originating RFC | 177 +=======================+===========================================+ 178 |crypto-types | [I-D.ietf-netconf-crypto-types] | 179 +-----------------------+-------------------------------------------+ 180 |truststore | [I-D.ietf-netconf-trust-anchors] | 181 +-----------------------+-------------------------------------------+ 182 |keystore | [I-D.ietf-netconf-keystore] | 183 +-----------------------+-------------------------------------------+ 184 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 185 +-----------------------+-------------------------------------------+ 186 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 187 +-----------------------+-------------------------------------------+ 188 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 189 +-----------------------+-------------------------------------------+ 190 |http-client-server | [I-D.ietf-netconf-http-client-server] | 191 +-----------------------+-------------------------------------------+ 192 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 193 +-----------------------+-------------------------------------------+ 194 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 195 +-----------------------+-------------------------------------------+ 197 Table 1: Label to RFC Mapping 199 1.2. Specification Language 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in BCP 204 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 1.3. Adherence to the NMDA 209 This document is compliant with the Network Management Datastore 210 Architecture (NMDA) [RFC8342]. For instance, trust anchors installed 211 during manufacturing (e.g., for trusted well-known services), are 212 expected to appear in (see Section 3). 214 1.4. Conventions 216 Various examples used in this document use a placeholder value for 217 binary data that has been base64 encoded (e.g., "BASE64VALUE="). 218 This placeholder value is used as real base64 encoded structures are 219 often many lines long and hence distracting to the example being 220 presented. 222 2. The "ietf-truststore" Module 224 This section defines a YANG 1.1 [RFC7950] module that defines a 225 "truststore" and groupings supporting downstream modules to reference 226 the truststore or have locally-defined definitions. 228 This section defines a YANG 1.1 [RFC7950] module called "ietf- 229 truststore". A high-level overview of the module is provided in 230 Section 2.1. Examples illustrating the module's use are provided in 231 Examples (Section 2.2). The YANG module itself is defined in 232 Section 2.3. 234 2.1. Data Model Overview 236 This section provides an overview of the "ietf-truststore" module in 237 terms of its features, typedefs, groupings, and protocol-accessible 238 nodes. 240 2.1.1. Features 242 The following diagram lists all the "feature" statements defined in 243 the "ietf-truststore" module: 245 Features: 246 +-- central-truststore-supported 247 +-- local-definitions-supported 248 +-- certificates 249 +-- public-keys 251 | The diagram above uses syntax that is similar to but not 252 | defined in [RFC8340]. 254 2.1.2. Typedefs 256 The following diagram lists the "typedef" statements defined in the 257 "ietf-truststore" module: 259 Typedefs: 260 leafref 261 +-- certificate-bag-ref 262 +-- certificate-ref 263 +-- public-key-bag-ref 264 +-- public-key-ref 266 | The diagram above uses syntax that is similar to but not 267 | defined in [RFC8340]. 269 Comments: 271 * All the typedefs defined in the "ietf-truststore" module extend 272 the base "leafref" type defined in [RFC7950]. 274 * The leafrefs refer to certificates, public keys, and bags in the 275 central truststore, when this module is implemented. 277 * These typedefs are provided as an aid to downstream modules that 278 import the "ietf-truststore" module. 280 2.1.3. Groupings 282 The "ietf-truststore" module defines the following "grouping" 283 statements: 285 * local-or-truststore-certs-grouping 286 * local-or-truststore-public-keys-grouping 287 * truststore-grouping 289 Each of these groupings are presented in the following subsections. 291 2.1.3.1. The "local-or-truststore-certs-grouping" Grouping 293 The following tree diagram [RFC8340] illustrates the "local-or- 294 truststore-certs-grouping" grouping: 296 grouping local-or-truststore-certs-grouping 297 +-- (local-or-truststore) 298 +--:(local) {local-definitions-supported}? 299 | +-- local-definition 300 | +-- certificate* [name] 301 | +-- name? string 302 | +---u ct:trust-anchor-cert-grouping 303 +--:(truststore) {central-truststore-supported,certificates}? 304 +-- truststore-reference? ts:certificate-bag-ref 306 Comments: 308 * The "local-or-truststore-certs-grouping" grouping is provided 309 soley as convenience to downstream modules that wish to offer an 310 option whether a bag of certificates can be defined locally or as 311 a reference to a bag in the truststore. 313 * A "choice" statement is used to expose the various options. Each 314 option is enabled by a "feature" statement. Additional "case" 315 statements MAY be augmented in if, e.g., there is a need to 316 reference a bag in an alternate location. 318 * For the "local-definition" option, the "certificate" node uses the 319 "trust-anchor-cert-grouping" grouping discussed in Section 2.1.4.7 320 of [I-D.ietf-netconf-crypto-types]. 322 * For the "truststore" option, the "truststore-reference" is an 323 instance of the "certificate-bag-ref" discussed in Section 2.1.2. 325 2.1.3.2. The "local-or-truststore-public-keys-grouping" Grouping 327 The following tree diagram [RFC8340] illustrates the "local-or- 328 truststore-public-keys-grouping" grouping: 330 grouping local-or-truststore-public-keys-grouping 331 +-- (local-or-truststore) 332 +--:(local) {local-definitions-supported}? 333 | +-- local-definition 334 | +-- public-key* [name] 335 | +-- name? string 336 | +---u ct:public-key-grouping 337 +--:(truststore) {central-truststore-supported,public-keys}? 338 +-- truststore-reference? ts:public-key-bag-ref 340 Comments: 342 * The "local-or-truststore-public-keys-grouping" grouping is 343 provided soley as convenience to downstream modules that wish to 344 offer an option whether a bag of public keys can be defined 345 locally or as a reference to a bag in the truststore. 347 * A "choice" statement is used to expose the various options. Each 348 option is enabled by a "feature" statement. Additional "case" 349 statements MAY be augmented in if, e.g., there is a need to 350 reference a bag in an alternate location. 352 * For the "local-definition" option, the "public-key" node uses the 353 "public-key-grouping" grouping discussed in Section 2.1.4.4 of 354 [I-D.ietf-netconf-crypto-types]. 356 * For the "truststore" option, the "truststore-reference" is an 357 instance of the "certificate-bag-ref" discussed in Section 2.1.2. 359 2.1.3.3. The "truststore-grouping" Grouping 361 The following tree diagram [RFC8340] illustrates the "truststore- 362 grouping" grouping: 364 grouping truststore-grouping 365 +-- certificate-bags {certificates}? 366 | +-- certificate-bag* [name] 367 | +-- name? string 368 | +-- description? string 369 | +-- certificate* [name] 370 | +-- name? string 371 | +---u ct:trust-anchor-cert-grouping 372 +-- public-key-bags {public-keys}? 373 +-- public-key-bag* [name] 374 +-- name? string 375 +-- description? string 376 +-- public-key* [name] 377 +-- name? string 378 +---u ct:public-key-grouping 380 Comments: 382 * The "truststore-grouping" grouping defines a truststore instance 383 as being composed of certificates and/or public keys, both of 384 which are enabled by "feature" statements. The structure 385 supporting certificates and public keys is essentially the same, 386 having an outer list of "bags" containing in inner list of objects 387 (certificates or public keys). The bags enable trust anchors 388 serving a common purpose to be grouped and referenced together. 390 * For certificates, each certificate is defined by the "trust- 391 anchor-cert-grouping" grouping Section 2.1.4.7 of 392 [I-D.ietf-netconf-crypto-types]. Thus the "cert-data" node is a 393 CMS structure that can be composed of a chain of one or more 394 certificates. Additionally, the "certificate-expiration" 395 notification enables the server to alert clients when certificates 396 are nearing or have already expired. 398 * For public keys, each public key is defined by the "public-key- 399 grouping" grouping Section 2.1.4.4 of 400 [I-D.ietf-netconf-crypto-types]. Thus the "public-key" node can 401 be one of any number of structures specified by the "public-key- 402 format" identity node. 404 2.1.4. Protocol-accessible Nodes 406 The following tree diagram [RFC8340] lists all the protocol- 407 accessible nodes defined in the "ietf-truststore" module, without 408 expanding the "grouping" statements: 410 module: ietf-truststore 411 +--rw truststore 412 +---u truststore-grouping 414 grouping local-or-truststore-certs-grouping 415 +-- (local-or-truststore) 416 +--:(local) {local-definitions-supported}? 417 | +-- local-definition 418 | +-- certificate* [name] 419 | +-- name? string 420 | +---u ct:trust-anchor-cert-grouping 421 +--:(truststore) {central-truststore-supported,certificates}? 422 +-- truststore-reference? ts:certificate-bag-ref 423 grouping local-or-truststore-public-keys-grouping 424 +-- (local-or-truststore) 425 +--:(local) {local-definitions-supported}? 426 | +-- local-definition 427 | +-- public-key* [name] 428 | +-- name? string 429 | +---u ct:public-key-grouping 430 +--:(truststore) {central-truststore-supported,public-keys}? 431 +-- truststore-reference? ts:public-key-bag-ref 432 grouping truststore-grouping 433 +-- certificate-bags {certificates}? 434 | +-- certificate-bag* [name] 435 | +-- name? string 436 | +-- description? string 437 | +-- certificate* [name] 438 | +-- name? string 439 | +---u ct:trust-anchor-cert-grouping 440 +-- public-key-bags {public-keys}? 441 +-- public-key-bag* [name] 442 +-- name? string 443 +-- description? string 444 +-- public-key* [name] 445 +-- name? string 446 +---u ct:public-key-grouping 448 The following tree diagram [RFC8340] lists all the protocol- 449 accessible nodes defined in the "ietf-truststore" module, with all 450 "grouping" statements expanded, enabling the truststore's full 451 structure to be seen: 453 module: ietf-truststore 454 +--rw truststore 455 +--rw certificate-bags {certificates}? 456 | +--rw certificate-bag* [name] 457 | +--rw name string 458 | +--rw description? string 459 | +--rw certificate* [name] 460 | +--rw name string 461 | +--rw cert-data trust-anchor-cert-cms 462 | +---n certificate-expiration 463 | {certificate-expiration-notification}? 464 | +-- expiration-date yang:date-and-time 465 +--rw public-key-bags {public-keys}? 466 +--rw public-key-bag* [name] 467 +--rw name string 468 +--rw description? string 469 +--rw public-key* [name] 470 +--rw name string 471 +--rw public-key-format identityref 472 +--rw public-key binary 474 grouping local-or-truststore-certs-grouping 475 +-- (local-or-truststore) 476 +--:(local) {local-definitions-supported}? 477 | +-- local-definition 478 | +-- certificate* [name] 479 | +-- name? string 480 | +-- cert-data trust-anchor-cert-cms 481 | +---n certificate-expiration 482 | {certificate-expiration-notification}? 483 | +-- expiration-date yang:date-and-time 484 +--:(truststore) {central-truststore-supported,certificates}? 485 +-- truststore-reference? ts:certificate-bag-ref 486 grouping local-or-truststore-public-keys-grouping 487 +-- (local-or-truststore) 488 +--:(local) {local-definitions-supported}? 489 | +-- local-definition 490 | +-- public-key* [name] 491 | +-- name? string 492 | +-- public-key-format identityref 493 | +-- public-key binary 494 +--:(truststore) {central-truststore-supported,public-keys}? 495 +-- truststore-reference? ts:public-key-bag-ref 496 grouping truststore-grouping 497 +-- certificate-bags {certificates}? 498 | +-- certificate-bag* [name] 499 | +-- name? string 500 | +-- description? string 501 | +-- certificate* [name] 502 | +-- name? string 503 | +-- cert-data trust-anchor-cert-cms 504 | +---n certificate-expiration 505 | {certificate-expiration-notification}? 506 | +-- expiration-date yang:date-and-time 507 +-- public-key-bags {public-keys}? 508 +-- public-key-bag* [name] 509 +-- name? string 510 +-- description? string 511 +-- public-key* [name] 512 +-- name? string 513 +-- public-key-format identityref 514 +-- public-key binary 516 Comments: 518 * Protocol-accessible nodes are those nodes that are accessible when 519 the module is "implemented", as described in Section 5.6.5 of 520 [RFC7950]. 522 * The protcol-accessible nodes for the "ietf-truststore" module are 523 an instance of the "truststore-grouping" grouping discussed in 524 Section 2.1.3.3. 526 * The reason for why the "truststore-grouping" exists separate from 527 the protocol-accessible nodes definition is to enable instances of 528 the truststore to be instantiated in other locations, as may be 529 needed or desired by some modules. 531 2.2. Example Usage 533 The examples in this section are encoded using XML, such as might be 534 the case when using the NETCONF protocol. Other encodings MAY be 535 used, such as JSON when using the RESTCONF protocol. 537 2.2.1. A Truststore Instance 539 This section presents an example illustrating trust anchors in 540 , as per Section 2.1.4. Please see Section 3 for an 541 example illustrating built-in values in . 543 The example contained in this section defines eight bags of trust 544 anchors. There are four certificate-based bags and four public key 545 based bags. The following diagram provides an overview of the 546 contents in the example: 548 Certificate Bags 549 +-- Trust anchor certs for authenticating a set of remote servers 550 +-- End entity certs for authenticating a set of remote servers 551 +-- Trust anchor certs for authenticating a set of remote clients 552 +-- End entity certs for authenticating a set of remote clients 554 Public Key Bags 555 +-- SSH keys to authenticate a set of remote SSH server 556 +-- SSH keys to authenticate a set of remote SSH clients 557 +-- Raw public keys to authenticate a set of remote SSH server 558 +-- Raw public keys to authenticate a set of remote SSH clients 560 Following is the full example: 562 566 567 569 570 571 trusted-server-ca-certs 572 573 Trust anchors (i.e. CA certs) used to authenticate server 574 certificates. A server certificate is authenticated if its 575 end-entity certificate has a chain of trust to one of these 576 certificates. 577 578 579 Server Cert Issuer #1 580 BASE64VALUE= 581 582 583 Server Cert Issuer #2 584 BASE64VALUE= 585 586 588 589 590 trusted-server-ee-certs 591 592 Specific end-entity certificates used to authenticate server 593 certificates. A server certificate is authenticated if its 594 end-entity certificate is an exact match to one of these 595 certificates. 597 598 599 My Application #1 600 BASE64VALUE= 601 602 603 My Application #2 604 BASE64VALUE= 605 606 608 609 610 trusted-client-ca-certs 611 612 Trust anchors (i.e. CA certs) used to authenticate client 613 certificates. A client certificate is authenticated if its 614 end-entity certificate has a chain of trust to one of these 615 certificates. 616 617 618 Client Identity Issuer #1 619 BASE64VALUE= 620 621 622 Client Identity Issuer #2 623 BASE64VALUE= 624 625 627 628 629 trusted-client-ee-certs 630 631 Specific end-entity certificates used to authenticate client 632 certificates. A client certificate is authenticated if its 633 end-entity certificate is an exact match to one of these 634 certificates. 635 636 637 George Jetson 638 BASE64VALUE= 639 640 641 Fred Flintstone 642 BASE64VALUE= 643 644 646 648 649 651 652 653 trusted-ssh-public-keys 654 655 Specific SSH public keys used to authenticate SSH server 656 public keys. An SSH server public key is authenticated if 657 its public key is an exact match to one of these public keys. 659 This list of SSH public keys is analogous to OpenSSH's 660 "/etc/ssh/ssh_known_hosts" file. 661 662 663 corp-fw1 664 665 ct:ssh-public-key-format 666 667 BASE64VALUE= 668 669 670 corp-fw2 671 672 ct:ssh-public-key-format 673 674 BASE64VALUE= 675 676 678 679 680 SSH Public Keys for Application A 681 682 SSH public keys used to authenticate application A's SSH 683 public keys. An SSH public key is authenticated if it 684 is an exact match to one of these public keys. 685 686 687 Application Instance #1 688 689 ct:ssh-public-key-format 690 691 BASE64VALUE= 692 693 694 Application Instance #2 695 696 ct:ssh-public-key-format 697 698 BASE64VALUE= 699 700 702 703 704 Raw Public Keys for TLS Servers 705 706 Raw Public Key #1 707 708 ct:subject-public-key-info-format 709 BASE64VALUE= 710 711 712 Raw Public Key #2 713 714 ct:subject-public-key-info-format 715 716 BASE64VALUE= 717 718 720 721 722 Raw Public Keys for TLS Clients 723 724 Raw Public Key #1 725 726 ct:subject-public-key-info-format 727 728 BASE64VALUE= 729 730 731 Raw Public Key #2 732 733 ct:subject-public-key-info-format 734 735 BASE64VALUE= 736 737 738 739 741 2.2.2. A Certificate Expiration Notification 743 The following example illustrates the "certificate-expiration" 744 notification (per Section 2.1.4.6 of [I-D.ietf-netconf-crypto-types]) 745 for a certificate configured in the truststore in Section 2.2.1. 747 =============== NOTE: '\' line wrapping per RFC 8792 ================ 749 751 2018-05-25T00:01:00Z 752 753 754 755 trusted-client-ee-certs 756 757 George Jetson 758 759 2018-08-05T14:18:53-05:00 761 762 763 764 765 766 768 2.2.3. The "Local or Truststore" Groupings 770 This section illustrates the various "local-or-truststore" groupings 771 defined in the "ietf-truststore" module, specifically the "local-or- 772 truststore-certs-grouping" (Section 2.1.3.1) and "local-or- 773 truststore-public-keys-grouping" (Section 2.1.3.2) groupings. 775 These examples assume the existence of an example module called "ex- 776 truststore-usage" having the namespace "http://example.com/ns/ 777 example-truststore-usage". 779 The ex-truststore-usage module is first presented using tree diagrams 780 [RFC8340], followed by an instance example illustrating all the 781 "local-or-truststore" groupings in use, followed by the YANG module 782 itself. 784 The following tree diagram illustrates "ex-truststore-usage" without 785 expanding the "grouping" statements: 787 module: ex-truststore-usage 788 +--rw truststore-usage 789 +--rw cert* [name] 790 | +--rw name string 791 | +---u ts:local-or-truststore-certs-grouping 792 +--rw public-key* [name] 793 +--rw name string 794 +---u ts:local-or-truststore-public-keys-grouping 796 The following tree diagram illustrates the "ex-truststore-usage" 797 module, with all "grouping" statements expanded, enabling the 798 truststore's full structure to be seen: 800 module: ex-truststore-usage 801 +--rw truststore-usage 802 +--rw cert* [name] 803 | +--rw name string 804 | +--rw (local-or-truststore) 805 | +--:(local) {local-definitions-supported}? 806 | | +--rw local-definition 807 | | +--rw certificate* [name] 808 | | +--rw name string 809 | | +--rw cert-data 810 | | | trust-anchor-cert-cms 811 | | +---n certificate-expiration 812 | | {certificate-expiration-notification}? 813 | | +-- expiration-date yang:date-and-time 814 | +--:(truststore) 815 | {central-truststore-supported,certificates}? 816 | +--rw truststore-reference? ts:certificate-bag-ref 817 +--rw public-key* [name] 818 +--rw name string 819 +--rw (local-or-truststore) 820 +--:(local) {local-definitions-supported}? 821 | +--rw local-definition 822 | +--rw public-key* [name] 823 | +--rw name string 824 | +--rw public-key-format identityref 825 | +--rw public-key binary 826 +--:(truststore) 827 {central-truststore-supported,public-keys}? 828 +--rw truststore-reference? ts:public-key-bag-ref 830 The following example provides two equivalent instances of each 831 grouping, the first being a reference to a truststore and the second 832 being locally-defined. The instance having a reference to a 833 truststore is consistent with the truststore defined in 834 Section 2.2.1. The two instances are equivalent, as the locally- 835 defined instance example contains the same values defined by the 836 truststore instance referenced by its sibling example. 838 =============== NOTE: '\' line wrapping per RFC 8792 ================ 840 844 845 847 848 example 1a 849 trusted-client-ca-certs 851 853 854 example 1b 855 856 my-trusted-client-ca-certs 857 858 Client Identity Issuer #1 859 BASE64VALUE= 860 861 862 Client Identity Issuer #2 863 BASE64VALUE= 864 865 866 868 869 871 872 example 2a 873 trusted-ssh-public-keys 875 876 877 example 2b 878 879 trusted-ssh-public-keys 880 881 corp-fw1 882 883 ct:ssh-public-key-format 884 885 BASE64VALUE= 886 887 888 corp-fw2 889 890 ct:ssh-public-key-format 891 892 BASE64VALUE= 893 894 895 897 899 Following is the "ex-truststore-usage" module's YANG definition: 901 module ex-truststore-usage { 902 yang-version 1.1; 903 namespace "http://example.com/ns/example-truststore-usage"; 904 prefix etu; 906 import ietf-truststore { 907 prefix ts; 908 reference 909 "RFC BBBB: A YANG Data Model for a Truststore"; 910 } 912 organization 913 "Example Corporation"; 915 contact 916 "Author: YANG Designer "; 918 description 919 "This module illustrates notable groupings defined in 920 the 'ietf-truststore' module."; 922 revision 2021-12-14 { 923 description 924 "Initial version"; 925 reference 926 "RFC BBBB: A YANG Data Model for a Truststore"; 927 } 929 container truststore-usage { 930 description 931 "An illustration of the various truststore groupings."; 932 list cert { 933 key "name"; 934 leaf name { 935 type string; 936 description 937 "An arbitrary name for this cert."; 938 } 939 uses ts:local-or-truststore-certs-grouping; 940 description 941 "An cert that may be configured locally or be 942 a reference to a cert in the truststore."; 943 } 944 list public-key { 945 key "name"; 946 leaf name { 947 type string; 948 description 949 "An arbitrary name for this cert."; 950 } 951 uses ts:local-or-truststore-public-keys-grouping; 952 description 953 "An public key that may be configured locally or be 954 a reference to a public key in the truststore."; 955 } 956 } 957 } 959 2.3. YANG Module 961 This YANG module imports modules from [RFC8341] and 962 [I-D.ietf-netconf-crypto-types]. 964 file "ietf-truststore@2021-12-14.yang" 966 module ietf-truststore { 967 yang-version 1.1; 968 namespace "urn:ietf:params:xml:ns:yang:ietf-truststore"; 969 prefix ts; 971 import ietf-netconf-acm { 972 prefix nacm; 973 reference 974 "RFC 8341: Network Configuration Access Control Model"; 975 } 977 import ietf-crypto-types { 978 prefix ct; 979 reference 980 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 981 } 983 organization 984 "IETF NETCONF (Network Configuration) Working Group"; 986 contact 987 "WG Web : 988 WG List : 989 Author : Kent Watsen "; 991 description 992 "This module defines a 'truststore' to centralize management 993 of trust anchors including certificates and public keys. 995 Copyright (c) 2021 IETF Trust and the persons identified 996 as authors of the code. All rights reserved. 998 Redistribution and use in source and binary forms, with 999 or without modification, is permitted pursuant to, and 1000 subject to the license terms contained in, the Simplified 1001 BSD License set forth in Section 4.c of the IETF Trust's 1002 Legal Provisions Relating to IETF Documents 1003 (https://trustee.ietf.org/license-info). 1005 This version of this YANG module is part of RFC BBBB 1006 (https://www.rfc-editor.org/info/rfcBBBB); see the RFC 1007 itself for full legal notices. 1009 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1010 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1011 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1012 are to be interpreted as described in BCP 14 (RFC 2119) 1013 (RFC 8174) when, and only when, they appear in all 1014 capitals, as shown here."; 1016 revision 2021-12-14 { 1017 description 1018 "Initial version"; 1019 reference 1020 "RFC BBBB: A YANG Data Model for a Truststore"; 1021 } 1023 /****************/ 1024 /* Features */ 1025 /****************/ 1027 feature central-truststore-supported { 1028 description 1029 "The 'central-truststore-supported' feature indicates that 1030 the server supports the truststore (i.e., implements the 1031 'ietf-truststore' module)."; 1032 } 1034 feature local-definitions-supported { 1035 description 1036 "The 'local-definitions-supported' feature indicates that 1037 the server supports locally-defined trust anchors."; 1038 } 1040 feature certificates { 1041 description 1042 "The 'certificates' feature indicates that the server 1043 implements the /truststore/certificate-bags subtree."; 1044 } 1046 feature public-keys { 1047 description 1048 "The 'public-keys' feature indicates that the server 1049 implements the /truststore/public-key-bags subtree."; 1050 } 1052 /****************/ 1053 /* Typedefs */ 1054 /****************/ 1056 typedef certificate-bag-ref { 1057 type leafref { 1058 path "/ts:truststore/ts:certificate-bags/" 1059 + "ts:certificate-bag/ts:name"; 1060 } 1061 description 1062 "This typedef defines a reference to a certificate bag 1063 in the truststore, when this module is implemented."; 1064 } 1066 typedef certificate-ref { 1067 type leafref { 1068 path "/ts:truststore/ts:certificate-bags/ts:certificate-bag" 1069 + "[ts:name = current()/../ts:certificate-bag]/" 1070 + "ts:certificate/ts:name"; 1071 } 1072 description 1073 "This typedef defines a reference to a specific certificate 1074 in a certificate bag in the truststore, when this module 1075 is implemented. This typedef requires that there exist a 1076 sibling 'leaf' node called 'certificate-bag' that SHOULD 1077 have the typedef 'certificate-bag-ref'."; 1078 } 1080 typedef public-key-bag-ref { 1081 type leafref { 1082 path "/ts:truststore/ts:public-key-bags/" 1083 + "ts:public-key-bag/ts:name"; 1084 } 1085 description 1086 "This typedef defines a reference to a public key bag 1087 in the truststore, when this module is implemented."; 1088 } 1090 typedef public-key-ref { 1091 type leafref { 1092 path "/ts:truststore/ts:public-key-bags/ts:public-key-bag" 1093 + "[ts:name = current()/../ts:public-key-bag]/" 1094 + "ts:public-key/ts:name"; 1095 } 1096 description 1097 "This typedef defines a reference to a specific public key 1098 in a public key bag in the truststore, when this module is 1099 implemented. This typedef requires that there exist a 1100 sibling 'leaf' node called 'public-key-bag' that SHOULD 1101 have the typedef 'public-key-bag-ref'."; 1102 } 1104 /*****************/ 1105 /* Groupings */ 1106 /*****************/ 1108 grouping local-or-truststore-certs-grouping { 1109 description 1110 "A grouping that allows the certificates to be either 1111 configured locally, within the using data model, or be a 1112 reference to a certificate bag stored in the truststore. 1114 Servers that do not 'implement' this module, and hence 1115 'central-truststore-supported' is not defined, SHOULD 1116 augment in custom 'case' statements enabling references 1117 to the alternate truststore locations."; 1118 choice local-or-truststore { 1119 nacm:default-deny-write; 1120 mandatory true; 1121 description 1122 "A choice between an inlined definition and a definition 1123 that exists in the truststore."; 1124 case local { 1125 if-feature "local-definitions-supported"; 1126 container local-definition { 1127 description 1128 "A container for locally configured trust anchor 1129 certificates."; 1130 list certificate { 1131 key "name"; 1132 min-elements 1; 1133 description 1134 "A trust anchor certificate."; 1135 leaf name { 1136 type string; 1137 description 1138 "An arbitrary name for this certificate."; 1139 } 1140 uses ct:trust-anchor-cert-grouping { 1141 refine "cert-data" { 1142 mandatory true; 1143 } 1144 } 1145 } 1146 } 1147 } 1148 case truststore { 1149 if-feature "central-truststore-supported"; 1150 if-feature "certificates"; 1151 leaf truststore-reference { 1152 type ts:certificate-bag-ref; 1153 description 1154 "A reference to a certificate bag that exists in the 1155 truststore, when this module is implemented."; 1156 } 1157 } 1158 } 1159 } 1161 grouping local-or-truststore-public-keys-grouping { 1162 description 1163 "A grouping that allows the public keys to be either 1164 configured locally, within the using data model, or be a 1165 reference to a public key bag stored in the truststore. 1167 Servers that do not 'implement' this module, and hence 1168 'central-truststore-supported' is not defined, SHOULD 1169 augment in custom 'case' statements enabling references 1170 to the alternate truststore locations."; 1171 choice local-or-truststore { 1172 nacm:default-deny-write; 1173 mandatory true; 1174 description 1175 "A choice between an inlined definition and a definition 1176 that exists in the truststore."; 1177 case local { 1178 if-feature "local-definitions-supported"; 1179 container local-definition { 1180 description 1181 "A container to hold local public key definitions."; 1182 list public-key { 1183 key "name"; 1184 description 1185 "A public key definition."; 1186 leaf name { 1187 type string; 1188 description 1189 "An arbitrary name for this public key."; 1190 } 1191 uses ct:public-key-grouping; 1192 } 1193 } 1194 } 1195 case truststore { 1196 if-feature "central-truststore-supported"; 1197 if-feature "public-keys"; 1198 leaf truststore-reference { 1199 type ts:public-key-bag-ref; 1200 description 1201 "A reference to a bag of public keys that exists 1202 in the truststore, when this module is implemented."; 1203 } 1204 } 1205 } 1206 } 1208 grouping truststore-grouping { 1209 description 1210 "A grouping definition that enables use in other contexts. 1211 Where used, implementations MUST augment new 'case' 1212 statements into the various local-or-truststore 'choice' 1213 statements to supply leafrefs to the model-specific 1214 location(s)."; 1215 container certificate-bags { 1216 nacm:default-deny-write; 1217 if-feature "certificates"; 1218 description 1219 "A collection of certificate bags."; 1220 list certificate-bag { 1221 key "name"; 1222 description 1223 "A bag of certificates. Each bag of certificates SHOULD 1224 be for a specific purpose. For instance, one bag could 1225 be used to authenticate a specific set of servers, while 1226 another could be used to authenticate a specific set of 1227 clients."; 1228 leaf name { 1229 type string; 1230 description 1231 "An arbitrary name for this bag of certificates."; 1232 } 1233 leaf description { 1234 type string; 1235 description 1236 "A description for this bag of certificates. The 1237 intended purpose for the bag SHOULD be described."; 1238 } 1239 list certificate { 1240 key "name"; 1241 description 1242 "A trust anchor certificate."; 1243 leaf name { 1244 type string; 1245 description 1246 "An arbitrary name for this certificate."; 1247 } 1248 uses ct:trust-anchor-cert-grouping { 1249 refine "cert-data" { 1250 mandatory true; 1251 } 1252 } 1253 } 1254 } 1255 } 1256 container public-key-bags { 1257 nacm:default-deny-write; 1258 if-feature "public-keys"; 1259 description 1260 "A collection of public key bags."; 1261 list public-key-bag { 1262 key "name"; 1263 description 1264 "A bag of public keys. Each bag of keys SHOULD be for 1265 a specific purpose. For instance, one bag could be used 1266 authenticate a specific set of servers, while another 1267 could be used to authenticate a specific set of clients."; 1268 leaf name { 1269 type string; 1270 description 1271 "An arbitrary name for this bag of public keys."; 1272 } 1273 leaf description { 1274 type string; 1275 description 1276 "A description for this bag public keys. The 1277 intended purpose for the bag SHOULD be described."; 1278 } 1279 list public-key { 1280 key "name"; 1281 description 1282 "A public key."; 1283 leaf name { 1284 type string; 1285 description 1286 "An arbitrary name for this public key."; 1287 } 1288 uses ct:public-key-grouping; 1289 } 1290 } 1291 } 1292 } 1294 /*********************************/ 1295 /* Protocol accessible nodes */ 1296 /*********************************/ 1298 container truststore { 1299 nacm:default-deny-write; 1300 description 1301 "The truststore contains bags of certificates and 1302 public keys."; 1303 uses truststore-grouping; 1304 } 1305 } 1307 1309 3. Support for Built-in Trust Anchors 1311 In some implementations, a server may define some built-in trust 1312 anchors. For instance, there may be built-in trust anchors enabling 1313 the server to securely connect to well-known services (e.g., an SZTP 1314 [RFC8572] bootstrap server) or public CA certificates to connect to 1315 arbitrary services using public PKI. 1317 Built-in trust anchors are expected to be set by a vendor-specific 1318 process. Any ability for operators to modify built-in trust anchors 1319 is outside the scope of this document. 1321 As built-in trust anchors are provided by the server, they are 1322 present in , if used. The example below illustrates 1323 what the truststore in might look like for a server in 1324 its factory default state. 1326 1331 1333 1334 Built-In Manufacturer Trust Anchor Certificates 1335 1336 Certificates built into the device for authenticating 1337 manufacturer-signed objects, such as TLS server certificates, 1338 vouchers, etc. 1339 1340 1341 Manufacturer Root CA Cert 1342 BASE64VALUE= 1343 1344 1346 1347 Built-In Public Trust Anchor Certificates 1348 1349 Certificates built into the device for authenticating 1350 certificates issued by public certificate authorities, 1351 such as the end-entity certificate for web servers. 1352 1353 1354 Public Root CA Cert 1 1355 BASE64VALUE= 1356 1357 1358 Public Root CA Cert 2 1359 BASE64VALUE= 1360 1361 1362 Public Root CA Cert 3 1363 BASE64VALUE= 1364 1365 1367 1368 1370 In order for the built-in bags of trust anchors and/or their trust 1371 anchors to be referenced by configuration, they MUST first be copied 1372 into . 1374 The built-in bags and/or their trust anchors MUST be copied into 1375 using the same "key" values if it is desired for the server 1376 to maintain/update them (e.g., a software update may update a bag of 1377 trusted public CA certificates used for TLS-client connections). 1379 Built-in bags and/or their trust anchors MAY be copied into other 1380 parts of the configuration but, by doing so, they lose their 1381 association to the built-in entries and any assurances afforded by 1382 knowing they are/were built-in. 1384 The built-in bags and/or their trust anchors are immutable by 1385 configuration operations. Servers MUST ignore attempts to modify any 1386 aspect of built-in bags and/or their trust anchors from . 1388 The following example illustrates how a single built-in public CA 1389 certificate from the previous example has been propagated to 1390 : 1392 1395 1397 1398 Built-In Public Trust Anchor Certificates 1399 1400 Certificates built into the device for authenticating 1401 certificates issued by public certificate authorities, 1402 such as the end-entity certificate for web servers. 1404 Only the subset of the certificates that are referenced 1405 by other configuration nodes need to be copied. For 1406 instance, only "Public Root CA Cert 3" is present here. 1408 No new certificates can be added, nor existing certificate 1409 values changed. Missing certificates have no effect on 1410 "operational" when the configuration is applied. 1411 1412 1413 Public Root CA Cert 3 1414 BASE64VALUE= 1415 1416 1418 1419 1421 4. Security Considerations 1423 4.1. Security of Data at Rest 1425 The YANG module defined in this document defines a mechanism called a 1426 "truststore" that, by its name, suggests that its contents are 1427 protected from unauthorized modification. 1429 Security controls for the API (i.e., data in motion) are discussed in 1430 Section 4.3, but controls for the data at rest cannot be specified by 1431 the YANG module. 1433 In order to satisfy the expectations of a "truststore", it is 1434 RECOMMENDED that implementations ensure that the truststore contents 1435 are protected from unauthorized modifications when at rest. 1437 4.2. Unconstrained Public Key Usage 1439 This module enables the configuration of public keys without 1440 constraints on their usage, e.g., what operations the key is allowed 1441 to be used for (encryption, verification, both). 1443 This module also enables the configuration of certificates, where 1444 each certificate may constrain the usage of the public key according 1445 to local policy. 1447 4.3. The "ietf-truststore" YANG Module 1449 The YANG module defined in this document is designed to be accessed 1450 via YANG based management protocols, such as NETCONF [RFC6241] and 1451 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1452 implement secure transport layers (e.g., SSH, TLS) with mutual 1453 authentication. 1455 The NETCONF access control model (NACM) [RFC8341] provides the means 1456 to restrict access for particular users to a pre-configured subset of 1457 all available protocol operations and content. 1459 None of the readable data nodes defined in this YANG module are 1460 considered sensitive or vulnerable in network environments. The NACM 1461 "default-deny-all" extension has not been set for any data nodes 1462 defined in this module. 1464 All the writable data nodes defined by this module, both in the 1465 "grouping" statements as well as the protocol-accessible "truststore" 1466 instance, may be considered sensitive or vulnerable in some network 1467 environments. For instance, any modification to a trust anchor or 1468 reference to a trust anchor may dramatically alter the implemented 1469 security policy. For this reason, the NACM extension "default-deny- 1470 write" has been set for all data nodes defined in this module. 1472 This module does not define any "rpc" or "action" statements, and 1473 thus the security considerations for such is not provided here. 1475 5. IANA Considerations 1477 5.1. The "IETF XML" Registry 1479 This document registers one URI in the "ns" subregistry of the IETF 1480 XML Registry [RFC3688]. Following the format in [RFC3688], the 1481 following registration is requested: 1483 URI: urn:ietf:params:xml:ns:yang:ietf-truststore 1484 Registrant Contact: The IESG 1485 XML: N/A, the requested URI is an XML namespace. 1487 5.2. The "YANG Module Names" Registry 1489 This document registers one YANG module in the YANG Module Names 1490 registry [RFC6020]. Following the format in [RFC6020], the following 1491 registration is requested: 1493 name: ietf-truststore 1494 namespace: urn:ietf:params:xml:ns:yang:ietf-truststore 1495 prefix: ts 1496 reference: RFC BBBB 1498 6. References 1500 6.1. Normative References 1502 [I-D.ietf-netconf-crypto-types] 1503 Watsen, K., "YANG Data Types and Groupings for 1504 Cryptography", Work in Progress, Internet-Draft, draft- 1505 ietf-netconf-crypto-types-21, 14 September 2021, 1506 . 1509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1510 Requirement Levels", BCP 14, RFC 2119, 1511 DOI 10.17487/RFC2119, March 1997, 1512 . 1514 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1515 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1516 . 1518 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1519 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1520 May 2017, . 1522 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1523 Access Control Model", STD 91, RFC 8341, 1524 DOI 10.17487/RFC8341, March 2018, 1525 . 1527 6.2. Informative References 1529 [I-D.ietf-netconf-http-client-server] 1530 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 1531 Servers", Work in Progress, Internet-Draft, draft-ietf- 1532 netconf-http-client-server-07, 18 May 2021, 1533 . 1536 [I-D.ietf-netconf-keystore] 1537 Watsen, K., "A YANG Data Model for a Keystore", Work in 1538 Progress, Internet-Draft, draft-ietf-netconf-keystore-22, 1539 18 May 2021, . 1542 [I-D.ietf-netconf-netconf-client-server] 1543 Watsen, K., "NETCONF Client and Server Models", Work in 1544 Progress, Internet-Draft, draft-ietf-netconf-netconf- 1545 client-server-23, 18 May 2021, 1546 . 1549 [I-D.ietf-netconf-restconf-client-server] 1550 Watsen, K., "RESTCONF Client and Server Models", Work in 1551 Progress, Internet-Draft, draft-ietf-netconf-restconf- 1552 client-server-23, 18 May 2021, 1553 . 1556 [I-D.ietf-netconf-ssh-client-server] 1557 Watsen, K., "YANG Groupings for SSH Clients and SSH 1558 Servers", Work in Progress, Internet-Draft, draft-ietf- 1559 netconf-ssh-client-server-25, 18 June 2021, 1560 . 1563 [I-D.ietf-netconf-tcp-client-server] 1564 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 1565 and TCP Servers", Work in Progress, Internet-Draft, draft- 1566 ietf-netconf-tcp-client-server-10, 18 May 2021, 1567 . 1570 [I-D.ietf-netconf-tls-client-server] 1571 Watsen, K., "YANG Groupings for TLS Clients and TLS 1572 Servers", Work in Progress, Internet-Draft, draft-ietf- 1573 netconf-tls-client-server-25, 18 June 2021, 1574 . 1577 [I-D.ietf-netconf-trust-anchors] 1578 Watsen, K., "A YANG Data Model for a Truststore", Work in 1579 Progress, Internet-Draft, draft-ietf-netconf-trust- 1580 anchors-15, 18 May 2021, 1581 . 1584 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1585 DOI 10.17487/RFC3688, January 2004, 1586 . 1588 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1589 the Network Configuration Protocol (NETCONF)", RFC 6020, 1590 DOI 10.17487/RFC6020, October 2010, 1591 . 1593 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1594 and A. Bierman, Ed., "Network Configuration Protocol 1595 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1596 . 1598 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1599 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1600 . 1602 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1603 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1604 . 1606 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1607 and R. Wilton, "Network Management Datastore Architecture 1608 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1609 . 1611 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1612 Touch Provisioning (SZTP)", RFC 8572, 1613 DOI 10.17487/RFC8572, April 2019, 1614 . 1616 Appendix A. Change Log 1618 This section is to be removed before publishing as an RFC. 1620 A.1. 00 to 01 1622 * Added features "x509-certificates" and "ssh-host-keys". 1624 * Added nacm:default-deny-write to "trust-anchors" container. 1626 A.2. 01 to 02 1628 * Switched "list pinned-certificate" to use the "trust-anchor-cert- 1629 grouping" from crypto-types. Effectively the same definition as 1630 before. 1632 A.3. 02 to 03 1634 * Updated copyright date, boilerplate template, affiliation, folding 1635 algorithm, and reformatted the YANG module. 1637 A.4. 03 to 04 1639 * Added groupings 'local-or-truststore-certs-grouping' and 'local- 1640 or-truststore-host-keys-grouping', matching similar definitions in 1641 the keystore draft. Note new (and incomplete) "truststore" usage! 1643 * Related to above, also added features 'truststore-supported' and 1644 'local-trust-anchors-supported'. 1646 A.5. 04 to 05 1648 * Renamed "trust-anchors" to "truststore" 1649 * Removed "pinned." prefix everywhere, to match truststore rename 1651 * Moved everything under a top-level 'grouping' to enable use in 1652 other contexts. 1654 * Renamed feature from 'local-trust-anchors-supported' to 'local- 1655 definitions-supported' (same name used in keystore) 1657 * Removed the "require-instance false" statement from the "*-ref" 1658 typedefs. 1660 * Added missing "ssh-host-keys" and "x509-certificates" if-feature 1661 statements 1663 A.6. 05 to 06 1665 * Editorial changes only. 1667 A.7. 06 to 07 1669 * Added Henk Birkholz as a co-author (thanks Henk!) 1671 * Added PSKs and raw public keys to truststore. 1673 A.8. 07 to 08 1675 * Added new "Support for Built-in Trust Anchors" section. 1677 * Removed spurious "uses ct:trust-anchor-certs-grouping" line. 1679 * Removed PSK from model. 1681 A.9. 08 to 09 1683 * Removed remaining PSK references from text. 1685 * Wrapped each top-level list with a container. 1687 * Introduced "bag" term. 1689 * Merged "SSH Public Keys" and "Raw Public Keys" in a single "Public 1690 Keys" bag. Consuming downstream modules (i.e., "ietf-[ssh/tls]- 1691 [client/server]) refine the "public-key-format" to be either SSH 1692 or TLS specific as needed. 1694 A.10. 09 to 10 1696 * Removed "algorithm" node from examples. 1698 * Removed the no longer used statements supporting the old "ssh- 1699 public-key" and "raw-public-key" nodes. 1701 * Added a "Note to Reviewers" note to first page. 1703 A.11. 10 to 11 1705 * Corrected module prefix registered in the IANA Considerations 1706 section. 1708 * Modified 'local-or-truststore-certs-grouping' to use a list (not a 1709 leaf-list). 1711 * Added new example section "The Local or Truststore Groupings". 1713 * Clarified expected behavior for "built-in" certificates in 1714 1716 * Expanded "Data Model Overview section(s) [remove "wall" of tree 1717 diagrams]. 1719 * Updated the Security Considerations section. 1721 A.12. 11 to 12 1723 * Fixed a copy/paste issue in the "Data at Rest" Security 1724 Considerations section. 1726 A.13. 12 to 13 1728 * Fixed issues found by the SecDir review of the "keystore" draft. 1730 A.14. 13 to 14 1732 * Added an "Unconstrained Public Key Usage" Security Consideration 1733 to address concern raised by SecDir. 1735 * Addressed comments raised by YANG Doctor. 1737 A.15. 14 to 15 1739 * Added prefixes to 'path' statements per trust-anchors/issues/1 1740 * Renamed feature "truststore-supported" to "central-truststore- 1741 supported". 1743 * Associated with above, generally moved text to refer to a 1744 "central" truststore. 1746 * Removed two unecessary/unwanted "min-elements 1" and associated 1747 "presence" statements. 1749 * Aligned modules with `pyang -f` formatting. 1751 * Fixed nits found by YANG Doctor reviews. 1753 A.16. 15 to 16 1755 * Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples. 1757 * Minor editorial nits 1759 Acknowledgements 1761 The authors especially thank Henk Birkholz for contributing YANG to 1762 the ietf-truststore module supporting raw public keys and PSKs (pre- 1763 shared or pairwise-symmetric keys). While these contributions were 1764 eventually replaced by reusing the existing support for asymmetric 1765 and symmetric trust anchors, respectively, it was only thru Henk's 1766 initiative that the WG was able to come to that result. 1768 The authors additionally thank the following for helping give shape 1769 to this work (ordered by first name): Balazs Kovacs, Eric Voit, 1770 Juergen Schoenwaelder, Liang Xia, Martin Bjoerklund, Nick Hancock, 1771 and Yoav Nir. 1773 Author's Address 1775 Kent Watsen 1776 Watsen Networks 1778 Email: kent+ietf@watsen.net